>On Mon, 11 Mar 2002, Linus Torvalds wrote:
>
>>Note that I've actually tried to read all patches, and right now they are
>>all in my tree (of course, the "all" is the Linus kind of "all", which
>>only includes the ones I actually _noticed_.
>>
>>That includes your AMD IDE driver change _and_ the oh-so-much-discussed
>>patches by Martin (which in turn included Pavel's change, which - together
>>with his changelog entry - seems to be the one that triggered the "lively
>>discussions").
>>
>
>I think you might want to offer an opinion (or edict, mandate, whatever)
>WRT taskfile. While I think that some protective editing of commands is
>desirable, useful, etc, I'm damn sure that some form of raw access is
>required long term to allow diagmostics. I wouldn't argue if that
>interface was required for low level format and other really drastic
>operations as well.
>
One sticking point seems to be the question of whether there needs to be
some amount of validation performed on the commands passed through the
taskfile interface. I don't think Andre buys into the argument that
most other kernel hackers understand, which is, "if userspace is allowed
to bang away at random i/o ports, why validate taskfile requests in the
kernel?"
And IMO, we should have some basic validation of taskfile requests in
the kernel...
Reason 1: Standard kernel convention. In other ioctls, we check basic
arguments and return EINVAL when they are wrong, even for privieleged
ioctls.
Reason 2: If you have multiple programs issuing ATA commands, you would
want a decent amount of synchronization, provided by the kernel, for the
multiple user processes and multiple kernel processes issuing requests.
Having the userspace commands come down a single spot in the kernel
code makes this job a lot easier, if not making the impossible possible :)
Regards,
Jeff
-
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/