Cc: Anders Eriksson <aeriksson@...>, Rafael J. Wysocki <rjw@...>, Jens Axboe <jens.axboe@...>, Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>
An example of this "aim higher", I think that we obviously should complete
the command if the controller says it's done with it (like the old
"drive_cmd_intr()" code used to do), but we might decide that printing a
warning would be the proper way to then also inform the user about the
fact that we expected the command to want more data, but it never did.
That way, the code not only handles the unexpected situation gracefully,
but the very fact that it was unexpected also gets logged.
[ And at that point your patch to make the specific SMART subcommands have
strict logic about the data direction will actually matter - although
maybe it turns out that there are _other_ tools that send other
commands, and we decide that the warning isn't useful after all! ]
The thing is, I know for a fact that some system vendors use Linux for
burn-in and testing/setup of their components, and I would not be in the
least surprised if some of them use HDIO_DRIVE_CMD to do some
vendor-specific stuff.
And I think it's a fine thing to try to use just one set of code (the
taskfile code) to drive all these special commands, but the fact is, the
old HDIO_DRIVE_CMD interface fundamentally doesn't even _have_ the
capability to specify the total taskfile state.
So we simply know as a fact that
(a) people do use an interface that used to work (HDIO_DRIVE_CMD)
and
(b) it will fundamentally *never* have complete taskfile state, so we
*have* to live with the fact that some of our commands simply don't
have the full state that the taskfile code may have historically
depended on but the old ide_drive_cmd() code didn't and cannot depend
on.
Your patch tries to fix (b), but we also know that it fundamentally simply
*cannot* fix it for all cases. So even trying to is really pretty futile,
I think (although we can obviously hope that nobody uses HDIO_DRIVE_CMD
any more for anything but SMART and really simple commands, but that
sounds rather unlikely).
Linus
--
