linux-kernel - ATA ULD (was Re: [PATCH 2/3] scsi: add scsi_device->alt

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] [day] [month] [year] [list]

Date:	Fri, 15 May 2009 15:44:57 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Tejun Heo <tj@...nel.org>, linux-ide@...r.kernel.org,
	jens.axboe@...cle.com, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, Mauelshagen@...Hat.com,
	dm-devel@...Hat.com, dan.j.williams@...il.com
Subject: ATA ULD (was Re: [PATCH 2/3] scsi: add scsi_device->alt_capacity)

James Bottomley wrote:
> On Sun, 2009-05-10 at 01:09 +0900, Tejun Heo wrote:
>> James Bottomley wrote:
>>> This is done at slightly the wrong level.  Capacity is actually a
>>> property of struct scsi_disk not struct scsi_device ... shouldn't
>>> alt_capacity be at the same level?
>> Hmmm... I think that was my first try and then I moved it to sdev for
>> some reason I can't rememer now.  I'll look into it again and try to
>> move it into sdev.
> 
> Really one of the things I was wondering is why even scsi_disk ...
> capacity is in there, but it's also in gendisk, so I've thought
> (admittedly never translated it to action) that we could just remove the
> duplication in scsi_disk.
> 
> This alt_capacity looks to be a pure ATA thing ... I can't find it in
> the SCSI specs and there doesn't seem to be a SAT equivalent of the
> commands.  Ideally, what should be happening is that the ata ULD would
> issue the capacity commands and just set the block alt_capacity without
> having to worry about transporting the value up and down the stack.
> Matthew Wilcox thought we could begin an implementation of the ATA uld
> using the ATA_16 command to transport it through SCSI ... this might
> provide the good reason to begin that.

hmmmmm.  Well, ATA ULD is certainly the long term goal.  My main worry 
would then be user impact & confusion, and increasing the difficulty of 
separating libata from SCSI by increasing difficulty of making SCSI 
emulation an optional piece.

At this point the SCSI emulation is not only a hack to get sd.c to do 
work for us, it is also part of the ABI expected of diagnostic tools and 
the like.  That complicates changes.

It is my hope that we can separate libata-scsi.c into a separate kernel 
module, thus at least making it _optional_, thus providing a path for 
CONFIG_ATA + !CONFIG_SCSI.

I do also agree that the ATA hacks can only go on for so long, before 
they start infecting SCSI.   e.g. there was a patch to add DMI check in 
sd.c for an ATA hardware special case.

So far the "ATA infection" has been thankfully limited to things that sd 
might need anyway, like suspend/resume (start/stop)

A "libsd" does not seem viable, though.  Might be better to
	cp sd.c ata-disk.c
and then iterate from there, over time.

	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/