Re: new tool: blktool

From: Bartlomiej Zolnierkiewicz
Date: Thu Aug 19 2004 - 10:54:14 EST



Hi,

On Thursday 19 August 2004 17:03, Mark Lord wrote:
> >> 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,

Most people used it for as much arbitrary commands as they could.

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

WRITE_SECTOR?

IDE version of HDIO_DRIVE_CMD only implements READ_SECTOR and it is
already an abuse of this ioctl (because it does PIO-in command if buffer
is provided and no-data command otherwise).

> 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).

IMO it is a perfect moment to add one generic interface and start
deprecating three strange ioctls (HDIO_DRIVE_CMD / HDIO_DRIVE_TASK /
HDIO_DRIVE_TASKFILE).

Bartlomiej
-
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/