On Fri, 17 Mar 2000, Guest section DW wrote:
> On Wed, Mar 15, 2000 at 10:50:48PM -0500, Eric Youngdale wrote:
>
> > It turned out to be a little easier than I thought. As it turns
> > out we use a kdev_t that is 16 bits for all platforms. That simplified
> > the job a bit. Mind you, that is a limit that may come back to haunt
> > us...
>
> Hmm. kdev_t is not 16-bit at all. It is a data type of unknown size
> and structure (outside of kdev_t.h). On over half of my machines it
> is a 32-bit pointer.
What exactly do you do to kdev_t.h in order to get anything other
than a 16-bit kdev_t? I knew it was theoretically possible to replace it
with something different - I just didn't think anyone did it in practice.
The major sticking point about using a larger kdev_t is that more
disks will fit per major. With a 16-bit dev_t, you can fit 16 disks. With
a 32 bit dev_t (i.e. a 16-bit minor), you can fit up to 4096 disks. The
memory consumption gets to be a bit on the high side if you pre-allocate
structures for 4096 disks in the event you don't need it.
The other problem with assigning more than 16 disks per major (and
a larger kdev_t) is that the kdev_t becomes unrepresentable if you have a
16-bit dev_t. With devfs this isn't a huge problem - there would just be
some user-visible outages when you use ls or stat() on /dev. I have no
idea how you should resolve this one - for now I am just punting and
sticking with 16 disks per major.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
