>>> how about implimenting /dev/{stdin,stdout,stderr,tty} in the fdesc
>>> code, but, including it always ?  such that fdesc is now mounted on
>>> /dev/fd.
>> Having any pathnames, like /dev/fd, wired into the kernel strikes me
>> as an extremely bad idea.
> i think you misunderstood me.

Yes, it appears I did.  Sorry about that.  I thought you were saying
that the kernel should come up with fdesc already mounted.

> currently, there is some code in the kernel to allow /dev/{stdin,..}
> to work.  there is also some code in fdesc to allow the _same_ things
> to work.  why not merge this code into the one, common, place, and
> have _both_ things use the same code -- for the exact same service.

/dev/std* as not provided by fdesc are character special devices whose
open routine invokes a somewhat ugly hack in open() - see fdopen() in
/sys/kern/kern_descrip.c.  /dev/std* as provided by fdesc are symlinks
to fd/0, fd/1, and fd/2, which do or don't exist according to the usual
fdesc rules; the fdesc open code invokes exactly the same ugly hack in
open() - see fdesc_open() in /sys/miscfs/fdesc/fdesc_vnops.c.

I see no opportunity for code sharing here that isn't already being
exploited.  The only difference is how the special-case hooks get
tripped; in one case it's via a very special device driver, in the
other it's via the filesystem-specific open routine.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu