Jens Axboe wrote:
On Thu, Jul 20 2006, Jeff Garzik wrote:
Jens Axboe wrote:
On Thu, Jul 20 2006, Jeff Garzik wrote:
James Bottomley wrote:
On Thu, 2006-07-20 at 17:27 -0400, Jeff Garzik wrote:
Since _no individual SCSI driver_ uses the block layer
tagging, it is likely that some instability and core kernel
development
will occur, in order to make that work.
That's not quite true: 53c700 and tmscsim both use it ... I could with
the usage were wider, but at least 53c700 has pretty regular and
constant usage ... enough I think to validate the block tag code (it's
been using it for the last three years).
Not for the case being discussed in this thread, adapter-wide tags.
That just means the map is shared, otherwise there should be little if
any difference.
AFAICS, no file in include/scsi/* or drivers/scsi/* ever calls
blk_queue_init_tags() with a non-NULL third arg.
grpe again, it's in scsi_tcq.h.
What tree are you looking at?
There is only one user in the entire tree, and NULL is hardcoded as the
third arg. This is 2.6.18-rc2:
Sorry, missed your non-NULL statement, I thought you meant in generel.
As long as you get the locking right for the map access, there's really
nothing that seperates shared vs non-shared tag mappings. So I don't
think it's a big deal.
If we don't encourage new drivers to use the block layer tagging, we
might as well not bother with it.
I don't disagree it's a good thing to have.
I only assert that a --completely unused-- sub-feature cannot be a merge
requirement for a new driver. That's an unreasonable standard. We have
a driver that is clean and works with all well-known and well-used APIs.
As I discovered painfully via libata, using an unused API upstream
(->eh_strategy_handler) can often be a destabilizing or limiting factor.
You _hope_ that this feature works, but it's far better IMO to debug an
unused core feature upstream. If the upstream driver breaks when
host-wide blktag support is added, then it's trivial to find where the
breakage occurred: the stex blktag-update patch.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
