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/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:51 EST