----- Original Message -----
From: Dan Jones <[EMAIL PROTECTED]>
To: Eric Youngdale <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 09, 2000 12:54 PM
Subject: Re: Problem
> Eric Youngdale wrote:
> >
> >
> > > In terms of adding extra devs- this is a quantity only pertinent
> > > for allocating extra space for loadable HBA rescans- this doesn't have
> > > anything to do with boot time probing with static linking, or if it
does,
> > you
> > > can always change the SD_EXTRA_DEVS to something reasonable (like
512).
> >
One other thought, as long as I am at it. In the long run I would like
to eliminate all of S?_EXTRA_DEVS. Some of these are harder than others -
in general the character devices are the easiest, and I believe that Doug
has actually finished sg. The next one on the hit list is the tape driver.
The correct way for these things to function would be for the driver to
automatically resize the arrays on the fly as new devices are added. This
naturally opens up the possibility of race conditions, and obviously some
careful thought needs to go into this to make sure that we don't introduce
any new races. For the datastructures that are used internally within sd,
sr, st, and sg this isn't *that* hard of a problem - it is a minor nuisance,
but not that hard.
The block devices are tricker as there are those silly arrays that the
rest of the kernel indexes into to find the device sizes and so forth.
CDROM and disk will be harder because of this, although cdrom will be the
easier of the two as there isn't the genhd crap related to partition tables.
Unfortunately the disk driver is probably the one of the most interest....
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
