Messages in this thread | | | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: new tool: blktool | Date | Thu, 19 Aug 2004 17:51:19 +0200 |
| |
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/
| |