linux-kernel - Re: [PATCH] libata: rewrite SCSI host scheme to be one per ATA host

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Apr 2009 07:00:54 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Grant Grundler <grundler@...gle.com>
CC:	linux-ide@...r.kernel.org, linux-scsi@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] libata: rewrite SCSI host scheme to be one per ATA host

Grant Grundler wrote:
> On Wed, Apr 22, 2009 at 2:09 AM, Jeff Garzik <jeff@...zik.org> wrote:
>> Currently, libata creates a Scsi_Host per port.  This was originally
>> done to leverage SCSI's infrastructure to arbitrate among master/slave
>> devices, but is not needed for most modern SATA controllers.   And I
>> _think_ it is not needed for master/slave if done properly, either.
>>
>> The patch below converts libata such that there is now a 1:1
>> correspondence between struct Scsi_Host and struct ata_host.  ATA ports
>> are represented as SCSI layer 'channels', which is more natural.
> 
> Jeff,
> So far in reading this, the only reasons I gather for changing this
> mapping are "not needed" and "is more natural". Data Center
> environments (not just Google's) like to track disks in many different
> ways, including the SCSI identifiers since this one "key" for physical
> location. Breaking the current mappings is going to cause some people
> a world of pain since they will need to manually build (and integrate)
> old->new maps of the SCSI identifiers. Can you propose some real,
> tangible benefit to making this change? (e.g. enables some other
> feature)

Sure there are compat issues, just like there are compat issues with the 
existing consensus goal of moving libata to the block layer -- part of 
which implies that ATA disks would be served via a "native" block device 
rather than drivers/scsi/sd.c.

So at least to me, it is axiomatic that these issues will be examined.

As to benefits, the phrase "more natural" means the code naturally 
aligns with existing object topologies (ata_host becomes analagous to 
Scsi_Host), which always has a long list of technical benefits.

- we get to remove all the ugly hacks currently in place that assume 
ata_port is _the_ first class object.
- we get to remove all the workarounds where SCSI assumes it manipulates 
all devices on a controller (not true in current libata)
- SCSI (soon block) host-wide busy, block etc functionality now works as 
expected
- it makes the libata conversion from SCSI to block layer easier
- it makes integration with SAS+SATA devices such as mvsas or ipr easier
- the list goes on; that is just off the top of my head, before my 
morning Mountain Dew

"more natural" also solves a longstanding user confusion/complaint about 
libata:  users expected that libata would export each ATA "channel" 
(bus) as a SCSI channel.


> Mark already pointed out this might cause issues with Error Handling
> (forcing a review of all that code). So before triggering other
> developers (e.g. HW vendors) do that kind of work I'd like to hear
> what the reward is going to be at the end.

Are you aware that EH is already receiving a stream of updates, moving 
it from SCSI to the block layer?  This area has been in constant motion 
since, well, Tejun arrived and started improving things!  :)

	Jeff




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/