Subject: Ok, we have been envoked.

From: [email-masked]
Date: Wed, 01 Apr 1992 11:03:38 EST

I had a bit of trouble getting this message out (this is a VMS box - need
I say more:), so I apologize if you receive more than one copy.

>...
>/dev/console should refer to the ENTIRE console, not just one virtual
>window. This is so that any error message that is printed to the console
>will come up on your screen (for the user at the machine itself) no matter
>which virtual console you are on.
>...

What if something goes bananas and constantly writes messages to
/dev/console.  You might have trouble getting typing in edgeways in
order to correct the situation (unless you have a terminal attached to
comm[0-3]).  I guess you could have some way of enabing messages to
one set of vc's only, so that one or more would remain idle.

If we're going to go with zero based, lets be consistent.  No
exceptions for the comm's ports.  One simple README should be able
to explain a consistent system. 

I'm not sure I like the zero (0) device being special/different from
the other devices (1-n) in some cases, and not in others.  Perhaps to
be consistent, the zero device should always be reserved for something
special.  And if there isn't anything special, there shouldn't be one.
If this were the case comm1 would probably be the appropriate name for
comm's port 1.

If there are going to many different types of controller perhaps I would
prefer a naming hierarchy.  It would certainly make it easier to handle
variants  (for example /svga/video-7/vram).  Drives  would be similar:

/hd/wd/0
/hd/wd/1
/hd/wd/2
/hd/scsi/0
/hd/scsi/1
/hd/scsi/2

---

From: [email-masked]
Date: Tue, 31 Mar 92 17:49:09 MST

--------

Some one should implement a syslog daemon, and log all non-fatal kernel
messages from printk() there.  I think that's my next project that I'll
get to next weeken d.

    /hd/wd/0
    /hd/wd/1
    /hd/wd/2
    /hd/scsi/0
    /hd/scsi/1
    /hd/scsi/2

1.  /dev should be flat.  A non-flat /dev breaks many programs.

2.  Names that long are heinous.

3.  Quick question : what chipset does an Amazing Technology 
	SVGA card use, A Star, ASKA, etc?  There are so many
	repackagings, OEM versions of cards, etc that 
	it is not even funny.  The end user should not be
	concerned with this mess, the drivers should sort it
	out using something like probe, as I've done with the
	SCSI drivers.  We want ONE device name for all frame buffers,
	ONE name for all SCSI disks, and so on.

The device drivers should handle all the messy specifics, sorting out
what type of hardware you really have, like the BSD device driver's
probe(), or what I've done with the SCSI drivers.  This eliminates 
any need for cluttering the namespace with the inumerable 
entries necessary to describe everything.