Re: Well knwon ports

[nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:]

>Over the weekend I was thinking about well known ports. It seems to me
>that CONS and KBD are no longer needed (yes, I am familiar with the
>startup race condition in VSTa).

cons and kbd are only well-known for purposes of providing a defined
place to complain into during bootup. We could get rid of them, but
it isn't really at the heart of what you're after, I think.

>Does anyone have any comments about these? If there is agreement, I'd
>like to ask that CONS be registered as /dev/console and KBD registered
>as /dev/keyboard, and that startup of user programs would include
>opening these files. (I know this will conplicate things a little, and
>that it'll require some parts of libc to be rewritten, but for
>orthagonality, and for MADO, it would make things simpler).

User programs inherit their stdin/stdout/stderr from their invoking
program--usually, login. In 1.2, because I wrote the RS-232 driver,
I enhanced login to take an optional argument which is the device
to open for input and output (actually, if one arg, it is both input
and output, if two, then the first is input and the second output).

No user program should ever need to manually open paths for his stdin/out/err.
If he did, /dev/console and /dev/keyboard would be the Wrong Thing, since
you could well be running on a telnet connection or serial port. You'd
either get a permission error, or else your program would start talking to
some unexpecting person!

The right thing for a windowing system would probably be to redirect
stdin/out/err into the windowing server, then start the shell. Optionally,
you could also insert a /dev/tty entry into the mount table and accept
further open()'s of this path. This is "optional", because most programs
use their inherited stdin/out/err, or else they close it and open it to,
say, a disk file.

I'd like to vote that cons/kbd remain well known addresses for now, because
they allow simple, dependable debugging of boot servers. When I'm debugging
boot server, I *like* things simple and dependable. I would also endorse
the plan that these addresses be used for nothing else, ever. In fact, with
the exception of their being the default stdin/out/err in login, they are
not used outside of boot servers (to the best of my recollection).

I'm unclear why MADO would use namer registry? There can be multiple
windowing systems; registering one as /dev/console would be visible
system-wide, which doesn't appear desirable. In Plan9's 8.5, the windowing
system redirects I/O, and mounts objects into the filesystem namespace.
This is visible only to the process and its descendents, which is generally
what a windowing system desires.

                                                        Andy
Received on Mon Dec 27 15:26:54 1993