Messages in this thread |  | | From | "Jonathan H. Pickard" <> | Subject | Re: SCSI device numbering (was: Re: Ideas for v2.1 | Date | Fri, 21 Jun 1996 23:16:25 -0700 (PDT) |
| |
H. Peter Anvin sez: > > My belief is that the only reasonable solution is to permit the user > > to control the scanning order (including allowing gaps). The *ideal* > > would be to let the user afiliate arbitrary device names which > > arbitrary controller-target-LUN tuplets, but if at least the > > controller scanning order is determined we're remotely OK.
Quoth Andrew E. Mileski: > On the same note, it is possible (not easy, but possible) to > have arbitrary major & minor numbers assigned to devices. > I don't advocate this as being the best solution, but it is > a possibility.
But why? That's more or less how it stands anyway.
> > That being said, as the Linux Device Registrar I strongly advice that > > 2.1 *must* be the time to increase the size of dev_t to a mininum of > > 32 bit; I personally advocate 64 bit with support for sparse > > allocation of major numbers.
I agree that we _must_ go 64-bit. However, I'd much rather see an 8-bit major number and a 56-bit minor number. Ta-da: SCSI problem solved (except for the buttload of inodes now being taken up =:^) ) This could be easily processed by most machines currently in existence (well, not much harder than 32M/32m) if the major is the lowest-addressed byte. The minor wouldn't be all too annoying if we allow for definite big-endian longword ordering (sorry, Pentium =:^) ).
> Using a 64-bit major/minor (32 bits for each) is likely to be ample > forever. This also gives us the opportunity to assign reasonable > new majors/minors (example: all block devices have bit 31 set).
We don't even need to. There's already bits in the filemode for that.
> A volume based fs device system would be neat, but I don't know > if it would be possible. It certainly would be nice to not worry > about which device held which fs - you could just "Plug-and-Play" :-)
It's possible, sure. But I get the funny feeling the battles between concept and specification (let alone implementation) are gonna be not a little bloody. =:^(
> -- > Andrew E. Mileski > mailto:aem@ott.hookup.net My home page http://www.redhat.com/~aem/ > Linux Plug-and-Play Project Leader. See URL http://www.redhat.com/pnp/ > > Red Hat Software sponsors these pages - I have no other affilitation > with Red Hat Software, and I have never used any of their products.
-- Jon Pickard * 149 Olive #45 * Paso Robles CA 93446 * +1 805 2399518 * 6372F5B9 KNOW YOUR SYSADMIN -- TECHNICAL MANIAC: Writes scripts that SEEM to be monitoring the system, but are actually encrypting large lists of passwords. Uses nearby nodes as beta test sites for worms. -Stephan Zielinski
|  |