Re: new tool: blktool

[Mark Lord]

> > 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:

"Ignoring"?  Hardly.  I even listed a few of them above.
But in practice, HDIO_DRIVE_CMD only requires support for a very
limited set of commands.  It was never intended for arbitrary
command acceptance.  And it's not like Joe User can abuse it,
since it requires SYSADMIN and RAWIO capabilities to execute.

The command subset that accounts for just about all uses of it today is:

SET_FEATURES, SMART, IDENTIFY, READ_SECTOR, WRITE_SECTOR.
Period.

Pretty easy to support those, especially in SATA.
I know, since I've just taken a couple of hours and added it
to my SATA/RAID driver (a queuing controller with tag support).

For more generic interface, Curtis's document looks rather good.
But for backward compatibility with existing tools like the
smartmontools and hdparm, all that is needed is a limited subset
of HDIO_DRIVE_CMD (for the opcodes listed above) and also
the closely related HDIO_DRIVE_TASK ioctl for some of the SMART
commands (all non-data).

Cheers
--
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")
-
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/