Re: One more change pushed to bk tree

[Luben Tuikov <luben@splentec.com>]

Doug Ledford wrote:
> 
> Well, before we go too far down this road, I do want to pipe up and
> publically announce how much I thoroughly *DETEST* that whole section of
> code with its totally convoluted hoop jumping crap that it does to avoid
> calling blk_init_queue() on each scan target.  Personally, if it were up
> to me I would make a much simpler/faster queue init routine, quit this
> crap of passing around and reusing the same pointer, and clean up *tons*
> of crap in the scsi scan code.  That being said, anything that increases
> the complexity of that code is bad IMHO.
> 
> Furthermore, one of my intended near future patches, pending review of the
> idea because this is a change that would touch *A LOT* of files, is to get
> rid of scsi_{build,release}_commandblocks entirely and instead change the
> scsi subsystem to use generic command blocks that are applicable to all
> hosts, modify all low level drivers to use the cmd->device pointer to get
> the host/bus/target id/lun values so that they don't need device specific
> command blocks, then to allocate a small pool of these on startup and lazy
> allocate/deallocate them as we run and as scsi_adjust_queue_depth() starts
> getting called for various devices.  If that happens, then most of the
> discussion about command blocks is moot.  Then, since currently I'm the
> only user of slave_alloc(), it would also be easy enough for me to make a
> rule that no device driver is allowed to hard code device numbers in thier
> alloced struct so that we could do this scanning of devices, not need to
> rebuild command blocks, not need to realloc slave structs, and still have
> everything work.  Good enough?

scsi_adjust_queue_depth() would ideally just change an integer,
say device->max_device_cmds or something like that (OSLT). This would play
nicely with int dev->device_cmds_held or int device_cmds_active OSLT, also
being an integer and it wouldn't matter if you _decrease_ the
max, but currently there are more active in the device. (you may
disallow this or set some policy if you wish, etc...)

As a spin off of this, if you set max_device_cmds to 0, you've
effectively turned off the device, but letting it complete what's
active -- one may not want to do this like that of course, but
mentioned here just as a consequence.

The point of all this is that this makes a lot more things a lot
more flexible and makes SCSI core shrink (long, long awaited).

BTW, you've mentioned this change many times before. I don't know
why you haven't implemented it yet, or how structural (non-cosmetic)
changes are voted for in linux-scsi for the SCSI layer, but
you have my vote on this change.

-- 
Luben