lkml.org 
[lkml]   [2004]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: new tool: blktool
Date

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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.088 / U:0.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site