Subject: Re: Friendlier EPERM - Access to detailed syscall errors in a ring buffer.
Date: Tuesday 8th January 2013 20:59:52 UTC (over 4 years ago)
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.