Re: Friendlier EPERM - Access to detailed syscall errors in a ringbuffer.

[Carlos O'Donell <carlos at systemhalted dot org>]

On 01/08/2013 02:34 PM, Eric Paris wrote:
> My thought was in the kernel to create a new buffer to dump some info
> when a EPERM/EACCES is going to be returned.  Userspace may or may not
> ever read it and it might be overwritten the next EPERM/EACCES.  I was
> thinking we could expose a representation of this buffer in
> a /proc/self/task/[tid]/blob file.  This file could be read after the
> EPERM/ACCESS.  It would have a layout which differed based on the reason
> for the denial.  I'd see it as something like (very very pseudo codie)

Some glibc functions make many kernel syscalls, any of which could
return EPERM/EACCESS. Which of those do you expose to the user?

Some glibc functions make many kernel syscalls, any of which could
return EPERM/EACCESS, but the POSIX function is not defined as
returning EPERM/EACCESS. What happens then?

If your thread takes a signal after setting errno, then there might
be any number of other syscalls before you print the error message.
Standard practice here for errno is for a signal handler to save
and restore the value before return. What is the user going to see
from their special function call?

Just a couple more things to think about as you consider the
creation of a new API function.

Note that this is starting to look a lot like the Win32 
GetLastError()/SetLastError(), so you may wish to look there for 
historical mistakes and corrections in such an API.

Personally I think as a user I'd rather see a ring buffer of
detailed syscall error information with an API to access that
ring buffer. That way I can choose to look at the last one or the
last 10 errors, and configure it such that I can make the ring
smaller or larger depending on my needs.

Is there a liblinux or is glibc the defacto standard for that? :-)

Cheers,
Carlos.