Hi,
although the comments in errno.h say that ERESTARTSYS should not be seen
by userland,many drivers seam to return it from their
file_operations.Should glibc convert this errno so that the user program
sees something meaningful?Because it does not.Is EINTR not a better errno
to return from the drivers?
Thanks.
On Thu, 5 Apr 2001, Jani Monoses wrote:
> although the comments in errno.h say that ERESTARTSYS should not be seen
> by userland,many drivers seam to return it from their
> file_operations.Should glibc convert this errno so that the user program
> sees something meaningful?Because it does not.Is EINTR not a better errno
> to return from the drivers?
ERESTARTSYS is a part of the api between the driver and the
signal-handling code in the kernel. It does not reach user-space (provided
of course that it's used appropriately in the drivers :)
When a driver needs to wait, and get awoken by a signal (as opposed to
what it's really waiting for) the driver should in most cases abort the
system call so the signal handler can be run (like, you push ctrl-c while
running somethinig that's stuck in a wait for an interrupt). The kernel
uses the ERESTARTSYS as a "magic" value saying it's ok to restart the
system call automagically after the signal handling is done. The actual
return-code is switched to EINTR if the system call could not be
restarted.
-Bjorn
On Thu, 5 Apr 2001, Bjorn Wesen wrote:
>
> ERESTARTSYS is a part of the api between the driver and the
> signal-handling code in the kernel. It does not reach user-space (provided
> of course that it's used appropriately in the drivers :)
As an example sound/via82cxxx_audio.c returns ERESTARTSYS from
via_dsp_open() .I suppose this _does_ reach userland right?
> When a driver needs to wait, and get awoken by a signal (as opposed to
> what it's really waiting for) the driver should in most cases abort the
> system call so the signal handler can be run (like, you push ctrl-c while
> running somethinig that's stuck in a wait for an interrupt). The kernel
> uses the ERESTARTSYS as a "magic" value saying it's ok to restart the
> system call automagically after the signal handling is done. The actual
> return-code is switched to EINTR if the system call could not be
> restarted.
>
> -Bjorn
>
Thanks, and by the way the comments in arch/cris regarding the issue are
useful too ;)
Jani.
On Thu, 5 Apr 2001, Jani Monoses wrote:
> On Thu, 5 Apr 2001, Bjorn Wesen wrote:
> > ERESTARTSYS is a part of the api between the driver and the
> > signal-handling code in the kernel. It does not reach user-space (provided
> > of course that it's used appropriately in the drivers :)
>
> As an example sound/via82cxxx_audio.c returns ERESTARTSYS from
> via_dsp_open() .I suppose this _does_ reach userland right?
No; system calls do not exit directly to userland, they exit through the
magic in entry.S (confusingly so :). If a signal is pending (which it is,
if down_interruptible fails) the return is made through do_signal, which
rewrites the return value and does the proper restarting.
(down_interruptible means it can be interrupted by a signal, btw - bad
drivers do sleep and semaphoring without _interruptible so if your HW is
bad the process can get stuck irrecoverably in the kernel)
/Bjorn