[8391] in linux-scsi channel archive
Re: SD_EXTRA_DEVS, what if...
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Fri Mar 17 15:05:34 2000
Date: Thu, 16 Mar 2000 20:29:45 -0500 (EST)
From: Eric Youngdale <eric@andante.org>
To: Guest section DW <dwguest@win.tue.nl>
Cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <20000317013948.A4675@win.tue.nl>
Message-ID: <Pine.LNX.4.10.10003162005470.754-100000@gwyn.tux.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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 majordomo@vger.rutgers.edu
