[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]