Subject: Re: /dev/[r]sd[5,6]* devices by default ?
To: None <port-sparc@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-sparc
Date: 01/10/2002 11:50:29
> If you put aside arguments like "it has always been that way" and
> "sysadmins should adopt to the system", I can really only think of
> three alternatives that make sense.  Here are the three alternatives
> and why they make sense:

> 1. In dev, you find all devices you can possibly connect to the system
>    - that way /dev would never change

> 2. In dev, you find all devices the current kernel supports
>    - that way you could see what devices are supported by that system

> 3. In dev, you find all devices currently probed in the system
>    - that way you could see what devices actually are active

1 and 2 are completely out of reach for any kernel that supports
starred devices (by which I mean stuff like "scsibus* at esp?" or
"sd* at scsibus? target ? lun ?" in config-speak); on one of my
systems, for example, option 1 would mean sd0 through sd167, and the
only reason it's not through sd223 is that the machine has only two
SBus slots physically present - something I don't think the kernel can
tell; option 2 would mean sd0 through an ill-defined limit imposed by
available memory, probably at least a few million.  If I had the xbox
lines in my config, I could potentially have a more or less indefinite
number of SBusses, so even option 1 would mean a very high limit - on
the order of 700, even if you can't chain xboxes the way the config
file implies you can.  And that's just sd, never mind all the rest.

Option 3 requires something like a devfs, which has been discussed
before; I recommend that nobody post about its pros or cons without
having read the past discussion on the subject.

I do note you've neglected

4. In dev, what's been created is present (ie, the status quo)
   - we know how to implement it today

> Todays implementation, where [...][,] may be an easy one to implement
> but I really can not see any arguments for the concept in itself.

The major argument I see for it is that we know how to implement it.
The second argument for it is that it trivially supports things like "I
want this partition, but no other, to be RW to this user" (think
database, run by database owner, writing to raw partition), which a
naïve devfs doesn't.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B