> On Thu, 7 Oct 1999 owner-linux-kernel-digest@vger.rutgers.edu wrote:
> > From: Horst von Brand <vonbrand@inf.utfsm.cl>
> > Date: Thu, 07 Oct 1999 17:32:14 -0400
> > Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) )
> >
> > Reasons against devfs:
> >
> > - - Permanent attributes are kludged on
> > - - Breaks filesystem semantics in several ways, makes it very hard to check
> > ramifications
> > - - Impacts system administration, making device managing a lot less Unixy
> > - - Impacts _every_ single driver in the kernel, even if it isn't used
> > - - What can be done with devfs can be done without it. Granted, it is less
> > convenient. But I add/remove devices from my machines perhaps once a
> > month, so that doesn't cut it for me.
>
> This thread initially started out talking about USB device allocation and
> has since evolved into a passionate debate on the pros and cons of devfs
> vs. no devfs. My comments are more oriented towards the former.
>
> I've not personally used devfs so I can't comment on its strong or weak
> points; however, Solaris 2.x (/devices) and Irix 6.5 have (/hw)
> hardware-graph type fs scenarios to which /dev files are symlinked and it
> seems to work well enough.
It would appear Solaris at least has some user-space proggie create
/devices, and then another one that creates /dev off of that. I'm guessing
that it just assigns major,minor's by counting from the beginning to the
end of the devices. I could be wrong on that, but in any case, it does
appear at least to still use major,minor, which really isn't terribly
scalable.
> Anyway, assuming an enivornment where devices are quite static and don't
> change more than a month at a time, while fine for some doesn't reflect
> other configurations which will become more common in the near future. USB
> but scratches the surface of the dynamic device allocation problem (and
> the limitations of 16 bit minor devices).
>
> Take for example, a switched Fibre Channel fabric configuration (such as
> the one here at the University of Minnesota which changes VERY often
> during develoment and test work). The Fibre Channel standard allows:
>
> 239 switches per fabric, 255 ports per switch, 126 devices per port
>
> Even accounting for interswitch links, that's about 7.6 million disk
> drives (or other devices) that could, in theory, be connected to one host.
>
> Those drives can move from one switch port to another switch port or from
> one switch to another switch on the fly. Further, the topology of the
> fabric can change on the fly. A device naming and allocation system which
> accounts for this would be great. Neither Solaris nor Irix handle this
> right now, it'd be nice if Linux could handle it whatever the solution
> finally is.
One thing Linux is based around to some extent is more the 'general'
case. Now it's true that often a good solution handles both the general
case and the specific cases, but that is not always the case. In order to
handle 7.6 million disk drives, each device would have to have around 3
bytes associated with it to give it a unique identifier. Here you would have
to have it where each device was numbered sequentially, assigning numbers
to the possible number of devices is not exactly practical unless you have
a very large space to draw from, and that seems excessive.
Stephen (Trying to come up w/ something that will make
everyone happy)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/