lkml.org 
[lkml]   [2000]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Direct access to hardware
Date
"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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.155 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site