Messages in this thread | | | Date | Wed, 23 Jul 2003 19:27:06 -0400 | From | "Bill Rugolsky Jr." <> | Subject | Re: kernel bug in socketpair() |
| |
On Wed, Jul 23, 2003 at 06:50:41PM +0100, Alan Cox wrote: > > otherwise there is a bug in the /dev/fd/N -> /proc/self/fd/N implementation > > and /dev/fd/N should be separated out to its (original) dup(atoi(N)) > > semantics > > I don't see a bug. I see differing behaviour between Linux and BSD on a > completely non standards defined item. Also btw nobody ever really wrote > a /dev/fd/ for Linux - it was just a byproduct of the proc stuff someone > noticed. I guess someone could write a Plan-9 style dev/fd or devfdfs > for Linux if they wanted.
I first posted about this several years ago, and it came up again earlier in the year; see:
http://hypermail.idiosynkrasia.net/linux-kernel/archived/2003/week14/0314.html
As HPA and I had previously discussed, ->open() methods always return a new file struct, so providing the dup() semantics would require a restructuring of the ->open() methods -- unless, (and this is a dirty hack,) one creates a devfdfs that abuses the ERESTART_RESTARTBLOCK mechanism to restart the open() syscall with dup() instead. This requires some minor pollution to the open() syscall path to interpret the error return, but should require no other changes.
Regards,
Bill Rugolsky
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |