[8336] in linux-scsi channel archive
Re: Problem
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Thu Mar 9 12:17:14 2000
Message-ID: <009001bf89e7$33c54440$4d0310ac@fairfax.datafocus.com>
From: "Eric Youngdale" <eric@andante.org>
To: <mjacob@feral.com>
Cc: <sjbuller@us.ibm.com>, "Eric Lee Green" <eric@estinc.com>,
<linux-scsi@vger.rutgers.edu>
Date: Thu, 9 Mar 2000 11:47:48 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
> > There is still a limit of 256 majors * 16 disks/major or 4096 disks
(an
> > over-estimate as some majors are unavailable). We won't worry about
that
> > for now... :-).
> >
>
> Well, maybe we should. It's not so much that 4096 is large, very soon it
won't
> be with a fabric- it's whether or not the lack of anything larger will
force a
> fabric midlayer to have to do a pick-n-choose policy for binding disks to
ids.
Sigh. Yes, we have been putting off expanding dev_t for ages and ages.
It is only Intel that is burdened with this relic of SVr3/Minix - the other
architectures were a bit smarter and used a more uptodate reference
platform.
There is the idea in some quarters that this *might* be easier with
devfs. Keep in mind that dev_t and kdev_t are not required to be the same
datatype. The idea is that dev_t is externally visible through various
interfaces that user applications use (primarily stat(), lstat() and
mknod()). The kdev_t could be 32 bits, and in a 32-bit kdev_t there would
be no reason why you couldn't have some much larger number of disks
represented. Thus if you were to "cat /dev/sdzz" and /dev were on /devfs,
then the kernel internally would pick up the kdev_t associated with the
node, and not a dev_t associated with an on-disk filesystem.
The tricky bit would be that if you were to stat a device with a kdev_t
that is unrepresentable in a dev_t, we need to come to agreement as to
exactly what should be returned. Should the call fail (not my
recommendation), or should we return a special value of dev_t that indicates
an unrepresentable value?
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
