Messages in this thread | | | Date | Mon, 11 Mar 2002 19:34:26 -0500 | From | Jeff Garzik <> | Subject | Re: [patch] My AMD IDE driver, v2.7 |
| |
Bill Davidsen wrote:
>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/
| |