[lkml]   [1996]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SCSI device numbering (was: Re: Ideas for v2.1
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
> My home page
> Linux Plug-and-Play Project Leader. See URL
> 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
monitoring the system, but are actually encrypting large lists of passwords.
Uses nearby nodes as beta test sites for worms. -Stephan Zielinski

 \ /
  Last update: 2005-03-22 13:37    [W:0.057 / U:1.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site