Re: [patch] My AMD IDE driver, v2.7

[Jeff Garzik]

J. Dow wrote:

>From: "Jeff Garzik" <[e-mail]>
>
>>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 needed
3) 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.

    Jeff