[...]
> 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.
Solaris machines tend to be a lot more uniform and orderly with their
devices than PCs. There just are no non-SCSI disks on this (SS4, Linux)
machine, not several dozen possible SCSI adapters, just a handful
alternatives for network cards. That sure makes managing devices a _lot_
simpler. Much of the mess in PCs is because PCs are a mess, generally and
in hardware terms speaking ;)
> 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).
"Will become more common in the near future" is the key here. Please, those
people who manage machines with hundreds of hot-pluggable devices step
forward. I'd assume your experiences will be a really interesting track in
the next LISA.
I've seen machines with hot-pluggable devices. For replacing a broken
device on the fly, without rebooting; not for adding/deleting devices all
day. Also something done rarely, but in cases where a few minutes downtime
costs dearly. Coupled with RAID and whatnot, so they really aren't
considered devices, just one piece of a larger device.
I've also seen machines where devices are changed all day. Well, you know
that: Insert this floppy, take it out, insert the next one, now pop in this
CD, what is on this Zip disk, maybe the tarball is here on this Jazz. Humm,
let's take a look at the tape here.
Yep, all current solutions for this suck. Some hard, some less so. The DOS
way (ported sucessfully with mtools to Unix) works fine, sort of. The
Solaris way, with devices that get automounted [Can be done in Linux too,
check TFM] on the fly is nice part of the time, a royal PITA when you try
to get off the beaten track ever so little. Mounting/unmounting by hand (as
CDs are handled now) isn't really nice, but gets the work done.
> 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.
Look at the Internet, it has to solve similar problems: The nodes have
names that are (well, almost) totally independent of the topology (think
UUCP, where you _had_ to know how to get to the destination), and _you_
have links (bookmarks, personal mail aliases) for resources on this
enormous network. You don't link to "devices", you link to "the latest
kernel tarball". Data addressing is the key, not device addressing. Devices
are means, just like inode numbers, sector positions and such that are
better forgotten.
Please, if you want to scale stuff up, try to look at other areas where
similar problems have been solved. Maybe you'll get a solution for free, at
least you'll learn something new.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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/