Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: Direct access to hardware | Date | Mon, 24 Jul 2000 20:13:50 +0200 (MET DST) |
| |
"A month of sundays ago Horst von Brand wrote:" > Andre Hedrick <andre@linux-ide.org> said: > > Willfully and now knowingly issuing commands that are otherwise not listed > > will be defined in ATA-ATAPI Specification can be deemed as violation of
Can be? Or ought to be? Or must be? You have to be very careful with wording here! I don't believe this is a quotation from the standard, simply because its wording is so lax. "Can be deemed" is meaningless in standardese ...
> > the Standard. Regardless if there are vendor-unique commands present or > > not, this would defined as accessing commands that are not considered the > > standard and deemed a violation. > > If Linux (the kernel) does so, it is certainly a bug which must be fixed
Does the standard say: "commands not defined in this standard MUST NOT be issued to the drive"?
If it does not say that, then they can be issued according to the standard, and that's that. If issuing them results in harm to the drive, then the manufacturer is at fault wrt the standard if harm ensues, because the standard allows it. Anything not prohibited in a specification is allowed by the specification - basic law of specification.
Any behaviour not defined by the specification is undefined, of course, and anything can result. If they don't say that issuing commands undefined by the standard MUST NOT harm the drive, then the drive manufacturer can make drives that are harmed by some bitblatts, and that's that too.
> ASAP. If a userland program provided by Western Digital, Seagate, IBM or > whatnot does so, it isn't Linux's fault.
It's neither's "fault".
> If you go by your interpretation, _no_ OS can ever be able to comply, as > they just can't ever prevent somebody writing a proggie that (given access) > bangs whatever garbage it wants at whatever piece of hardware it wants to.
Eh? An O/S does precisely that job of reducing access to a well defined set of interfaces that only allow "correct" modes of (hopefully sufficiently useful) behaviour.
As far as I can gather ..
a) someone has provided a generic interface to drives in the kernel in order to make use of future proprietary command sets undocumented in any standard.
b) someone else has realized that you can use this generic interface to fry some drives, by sending them commands which they are not required by the standard to interpret safely, and which in fact they interpret harmfully (which I am willing to bet is allowed by the standard).
Now it's back to the question of what the standard really says about this. What does it say?
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |