>From: "Jeff Garzik" <jgarzik@mandrakesoft.com>>>>Second, if you are issuing device commands from userspace, you need to >>deal with synchronization with the commands being issued from kernel space.>>>Generally speaking, yes.>cool

>>Third, if you have synchronization, that's a good and easy point to add >>-optional- filtering.>>>And while I see your point I still ask, "But why?" To make this work the>way it should work you will need a special table of normally disallowed>commands that are allowed for each specific device on the IDE buses>within a machine.>[...]

>It might be a good exercise, Jeff, to define the filters in such a way>that potentially harmful commands can be adequately filters while other>potentially "saving" commands can be allowed even if they differ only in>parameters. It is also interesting to note that direct userland ATA and>I'm afraid I may have been confusing to the casual reader, because the current thread of discussion mutated from talking about (among other things) implementation details of the existing ATA raw command "filter" and the existing interface for issuing raw ATA commands.

You can, certainly, make a filter that addresses the issues you list. The existing filter is mainly a correctness filter -- it ensures that only known and standard ATA commands are passed down to the actual devices. It filters out vendor-specific commands as well as potentially nefarious future commands like COPYPROTECT or somesuch.

So, to summarize my points on the thread so far (as modified by Linus's responses to me):

1) There should be a raw device command interface (not ATA or SCSI specific)2) There should be kernel interfaces for the standard cases, so that the raw device command interface is often not needed3) There should be capability to optionally install filter the raw device command interface. The filter is built into the kernel at compile-time, but can also be disabled at boot time.