Re: new tool: blktool

[Jeff Garzik]

Mark Lord wrote:
>  > http://www.t10.org/ftp/t10/document.04/04-262r1.pdf
>
> Ahh.. my buddie Curtis has been busy of late, I see.
>
> I'll implement this in hdparm and the SATA/RAID driver
> that I'm working on.  Will you (Jeff) do the same in libata?

I plan on providing _some_ way of executing arbitrary taskfiles, 
possibly more than one way.  I haven't decided upon the best route. 
Since T10 took my command protocol suggestions into account in the above 
proposal, implementing that would be an efficient route to the 
arbitrary-taskfiles feature.


> But HDIO_DRIVE_CMD is rather easy to implement as well,
> and perhaps both should be there for an overlap.
>
> Especially since the former is in rather widespread use right now.
> Yup, it's missing a separate data-phase parameter,
> and lots of taskfile stuff, but it's configured by default
> into every kernel (the same is not true for taskfile support),
> and there's really only a few limited cases of it being used
> for non-data commands:  IDENTIFY, SMART, and the odd READ/WRITE
> SECTOR (pio, single sector).

If HDIO_DRIVE_CMD was easy to do, I would have already done it.  I agree 
with you that supporting it has benefits, but you are ignoring the 
obstacles:

* without taskfile protocol, it is _impossible_ to execute some vendor 
reserved commands
* without taskfile protocol, and without a lookup table, it is 
impossible to distinguish between [non-data | data-in | data-out] on 
some controllers.  Current IDE driver does "execute and pray we can 
guess from controller behavior" which definitely won't work in a lot of 
situations.

Modern SATA controllers need to set up the DMA engine beforehand -- for 
the entire transfer -- including for PIO data xfer commands.

HDIO_DRIVE_CMD tells me nothing about data direction or taskfile 
protocol.  It forces you to guess :(

libata is designed to be flexible enough to execute the full breadth of 
the ATA command set on whatever host controller you pick -- PCI PATA, 
paride, SATA, ATA-over-ethernet, or whatever zany technology you choose. 
 But all that flexibility demands a bit more from the software side of 
things, command protocol in this case.  That's why I the T10 04-262r1 
proposal spec.

	Jeff


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