[RFC]: 64 bit LUN/Tags, dummy device in host_queue, host_lock <-> LLDD reentrancy

[Luben Tuikov <luben@splentec.com>]

Here's some of the things which have been looming in my mind for
some time now. Nothing important really, but I felt at least to
share it with you guys, just to keep in mind, that's all.
Comment at will.


* SAM-3 specifies that a LUN is 64 bit. While there may not
be any devices which actually even come close to using this
huge space, it provides different _addressing__modes_.

This very nicely fits LUN virtualization (iSCSI, LUN masking, etc),
and would allow one to do magic for storage devices (IP SANs, etc).

A 64 bit LUN could be presented to userspace which may/can then
present a nice ``picture'' (GUI or what not) of the underlying
physical/virtual (depending on the SCSI port name/id) storage
network.

(E.g. iSCSI communicates 64 bit LUNs only...)


* SAM-3 specifies that tags are 64 bit. It is not inconcievable that
a Task Manager (LUN structure, SAM-3, 4.8, 4.12) would use
those tags to order/id/whatnot the tasks it receives for
execution.

A really, leally long shot: Now that they are being moved up to
the block layer, it may be convenient to define them as such.


* In scsi_scan.c :: void scan_scsis(), select_queue_depths() is called
when there is a _dummy_ device in host_queue. This comes from
doing that juggle with SDpnt and oldSDpnt, allocating it in one
place and freeing it in another...

So when select_queue_depths() is called, in the host_queue, there's
_one__more_ device than there really should be, because of that SDpnt/oldSDpnt.

I filter the dummy SDpnt in select_queue_depths() by checking
vendor, model, rev and attached. But I'd rather
just get only the _actual_ devices in the host_queue, by
probably getting rid of that SDpnt/oldSDpnt juggle logic.


* It seems to me that the host_lock exists just to indirectly
impose/hint/etc. reentrancy of the LLDD methods exposed to the kernel.

Isn't the next step to stipulate that all methods of LLDDs should
be renentrant in and of themselves (which are exposed to the kernel
of course). That is, they'll have to achieve their own reentrancy
via their own locks and queues. Wouldn't this be a cleaner approach?

The kernel will have one less thing to worry about.

I realize that some LLDD will be really easy to convert and
other will have to undergo deep surgery, but this kind
of reentrancy seems to be implied by the host lock.

-- 
Luben