On Thu, May 22, 2025 at 03:59:14PM +, Brooks Davis wrote:
> On Thu, May 22, 2025 at 08:04:19AM +0300, Konstantin Belousov wrote:
> > On Wed, May 21, 2025 at 11:23:12PM +, Brooks Davis wrote:
> > > On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote:
> > > > In short, I'd love to wid
On Thu, May 22, 2025 at 08:04:19AM +0300, Konstantin Belousov wrote:
> On Wed, May 21, 2025 at 11:23:12PM +, Brooks Davis wrote:
> > On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote:
> > > In short, I'd love to widen the interface, but there's a number of
> > > practical
> > > issue
On Wed, May 21, 2025 at 11:23:12PM +, Brooks Davis wrote:
> On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote:
> > In short, I'd love to widen the interface, but there's a number of practical
> > issues in the way.
>
> I think caching something in the kernel of later retrieval or add
On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote:
> In short, I'd love to widen the interface, but there's a number of practical
> issues in the way.
I think caching something in the kernel of later retrieval or adding a
new return path to the ABI is the wrong way around. Instead I thi
Brooks Davis writes:
> FWIW, I found it useful that we made SYSERRCAUSE take a format string.
> When debugging complicated mmap usage errors, [...]
The main problem with format strings is that then we need memory
(pre-)allocation.
My proposal gives up that level of precision in favor o
On Wed, May 21, 2025 at 07:22:29AM +, Poul-Henning Kamp wrote:
> The ip# on bridge member interfaces is yet another example of why
> "EINVAL" is the undisputedly least helpful errno of them all.
>
> The laconic "Invalid argument" leaves both the userland programmer
> and the user to guess what
Warner Losh writes:
> In short, I'd love to widen the interface, but there's a number of practical
> issues in the way.
Not really ?
Our kernel is not I18N'ed and we have no plans to do so.
That means that there is absolutely no point in taking a big detour over
enumerating all possibl
On Wed, 21 May 2025 at 10:08, Warner Losh wrote:
The other way to report this would be via something new. There's no new
> register we can report this on in most architectures: they all have
> proscribed
> roles that we can't change (or that would be unwise for use to change).
> There's
> some te
On Wed, May 21, 2025 at 10:23 AM Andriy Gapon wrote:
>
> On 21/05/2025 10:28, Lexi Winter wrote:
> > you are completely right. since we (for some reason, that i don't
> > really understand) can't add new error codes to errno, we should stop
> > using errno to indicate errors except where POSIX re
On 2025-05-21 00:22, Poul-Henning Kamp wrote:
The ip# on bridge member interfaces is yet another example of why
"EINVAL" is the undisputedly least helpful errno of them all.
The laconic "Invalid argument" leaves both the userland programmer
and the user to guess what might be wrong.
That's ok-i
Poul-Henning Kamp:
> The ip# on bridge member interfaces is yet another example of why
> "EINVAL" is the undisputedly least helpful errno of them all.
>
> The laconic "Invalid argument" leaves both the userland programmer
> and the user to guess what might be wrong.
you are completely right. si
The ip# on bridge member interfaces is yet another example of why
"EINVAL" is the undisputedly least helpful errno of them all.
The laconic "Invalid argument" leaves both the userland programmer
and the user to guess what might be wrong.
That's ok-ish for read(2) where the possibilities are so fe
12 matches
Mail list logo
