> > 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 [EMAIL PROTECTED]
