Re: new tool: blktool
From: Bartlomiej Zolnierkiewicz <hidden>
Date: 2004-08-19 15:52:49
Also in:
lkml
Hi, On Thursday 19 August 2004 17:03, Mark Lord wrote:
quoted
quoted
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