[lkml]   [1996]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SCSI device numbering (was: Re: Ideas for v2.1
> 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.

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.

> I do *not* agree that the ISA/EISA/PnP/PCI bus identifier should be
> encoded -- it is simply too hardware dependent.

I don't agree with you here, but I agree with your intentions.
Multiple controllers on ANY bus with multiple devices and multiple
LUNs are going to be the same for any SCSI system.

It sounds like you are advocating a generic disk naming scheme
(ie. don't distinguish SCSI from IDE from whatever).

> 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've looked over the code, and went through the kdev_t.h file.
I don't like the idea of using different internal/external majors/minors.
Is it necessary? What software relies on majors/minors being constant,
or of a specific type?? (I'm not aware of any software looking at them.)

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).

I don't think we need to do the IPv6 thing = 128-bits (enough to
count the number of electrons in the known universe).

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" :-)

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.

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