Subject: Re: struct emul modification
To: None <tech-kern@netbsd.org>
From: Emmanuel Dreyfus <p99dreyf@criens.u-psud.fr>
List: tech-kern
Date: 05/19/2001 20:46:09
> BTW, I looked at newpipe again and it DOES send the SIGIO for pipe
> (I haven't tested actual behaviour, just stared at the code).
> This also means FreeBSD sends the SIGIO for pipe too. I'm not sure
> about Solaris though; I assume that if Solaris doesn't send
> the signal, it's merely an overlooking rather than a design decision.
Which FreeBSD version are you talking about? I just double checked
FreeBSD-4.2, there is no SIGIO fired on read() when async I/O is
selected on the write end of the pipe. But it does send a SIGIO when
async I/O is selected on the read end of the pipe. This problem is a
real mess.
Here is the global picture, as far as I know:
A = SIGIO on read() when async I/O is enabled on write end of pipe
B = SIGIO on write() when async I/O is enabled on read end of pipe
C = SIGIO on read() when async I/O is enabled on write end of socket
D = SIGIO on write() when async I/O is enabled on read end of socket
A B C D
NetBSD 1 1 1 1
FreeBSD 0 1 1 1
OpenBSD 0 0 1 1
Linux 0 0 0 1
SunOS 0 0 0 1
OSF/1 1 1 1 1
Darwin 1 ? 1 ?
AIX 0 ? 1 ?
1 = it does
0 = it does not
? = I have not tested
> I THINK this _should_ be handled in Linux-specific code. The most
> simple solution would be to hook a check for descriptor being
> a pipe in linux_sys_ioctl() for FIOASYNC. Easy, avoids pollution
> of generic code and eases integration of alternate pipe implementations.
Well this is okay to fix Linux and SunOS pipes, except that I will need
someone to test the fix for SunOS. Having the fix in sys_socket was good
because it was possible to fix both emulations at once.
But then if we want to fix Linux and SunOS sockets or FreeBSD pipes, we
will need to modify code in sys/kern/sys_socket.c. I thought about
adding a sowakeup_nosigio() that would be called in uipc_usrreq() for
the PRU_RCVD case (it corresponds to a read()) if the emulation does not
want a SIGIO on read.
If we decide that sys_socket is definitively the wrong place for fixing
this, how should it be handled?
--
Emmanuel Dreyfus.
p99dreyf@criens.u-psud.fr