Subject: Re: pipes from FreeBSD and the NetBSD async I/O bug
To: Jason R Thorpe <firstname.lastname@example.org>
From: Emmanuel Dreyfus <email@example.com>
Date: 05/01/2001 09:40:09
> > Umm... If the emulation changes, we need to review all open sockets on
> > execve(), and modify their flags according to the new emulation. Is th=
> > reasonable? I got no idea of the overhead this would introduce.=20
> Err, maybe.
Maybe the right fix is a flag in struct emul. That way when a process
emulation changes, the flag is automatically changed, I don't have
anything to add to exec() implementation.
There is a few issues remaining:
1) What about a UNIX socket with a Linux process at one hand and a
NetBSD process at the other hand? I beleive it should be the writer that
cause the BSD SIGIO to be disabled or not, since it is the process that
will receive the signal. But what about when sowakeup send the signal to
a whole process group? I see no way of handling this in a clean way.
2) It seems we also need to be able to distinguish UNIX sockets that are
in fact pipes, because some OSes like FreeBSD fail on the UNIX socket
test but suceed on the pipe test. Here I have to add a SO_ISAPIPE in the
socket so_options field, I see no other way of doing it.
3) We need the old behavior on new pipes if we want to be able to
emulate digital UNIX.
Emmanuel Dreyfus. firstname.lastname@example.org
X Window, c'est un millefeuille avec une couche de cr=E8me patissi=E8re, un=
de ketchup, et une d'anchois. Faut aimer. Mais c'est vrai que c'est un=20
systeme ouvert: on peut ajouter des pepites de chocolat et des c=E2pres