Re: Direct access to hardware

From: Andre Hedrick (andre@linux-ide.org)
Date: Mon Jul 24 2000 - 03:34:44 EST


> Ah! Finally some clarity! The drive manufacturers have dumped *their*
> responsibility onto the OS. If *we* don't knuckle under this
> *official edict* and our hard drive(s) get clobbered by an "improper"
> command then our warranty is *void*. I wonder if this cute shenanagin
> will hold up in court?

I bet we find out soon......

Since the current form of the OS defaults to no protection against the
rules and usage of the spec.

It defines "How one is to communicate with the device".
Additionally defines, "Which commands may be used, and their method".

Willfully and now knowingly issuing commands that are otherwise not listed
will be defined in ATA-ATAPI Specification can be deemed as violation of
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.

Understand that we as the T13 committee operate under the
procedures of The American National Standards Institute by
Information Technology Industries Council (ITI),
1250 Eye Street, N.W., Suite 200, Washington, DC 20005-3922

http://www.ncits.org/

Please understand that SCSI (T10), HI(IPI)/FC (T11), FDDI (T12) all are
run by there industries and define the rules by majority.

I would expect that an officer of the court would ask the ruling body of
the standard if this was a violation. This is only logical, IMHO.
Given that option and view point, I would have to agree that it does
violate the standard even though I am responsible for Linux to be
compliate to the standard in "The Default Configuration Mode".

Basically, I have to cut my own throat because all of my peers intend on
holding the knife there. So the willful act of preventing me for
correction the issue, regardless of what anyone thinks, should remove me
from copablity and place those making the decision there in my place.

Now you place me in the position that I would have to obstain or rule
against my peers, please do not put me in that position or any other
maintainer that attempts to do everything and anything to protect Linux.
This includes joining professional societies to insure that Linux will be
conforming and not violate the rules of that body. This will also ensure
that Linux can receive certification of compliance in the 'default-defined'
configuration mode.

Why is this so wrong to do?
Will you explain why you all would willfully want,
        : to endanger me personally?
        : void product warrenties?
        : dirty the reputation of this fine product?
        : make copable commerial distrutors of Linux, by not allowing?

IMHO, the very strengh of Linux depends on its configurablity.
I find this the most attractive feature and strenght if the Penguin.

I have to admit that I was out of control, very ugly, and rude.
For that I owe an apology to all on this list.
You must see that why I am struggling with the responsiblities given to
me by Linus and now trusted by the masses and the knowledge that all of
you are denying me ablity to protect, improve, and make more acceptable
for Linux to be used as a potential replacement for other OS's.

Final Note:

Few know that I was invited to become a member by several different
companies that are long standing members. You should also know that some
think it was a mistake because I point out that is messy and makes if more
difficult for driver writers to develop that model/design. Part of what I
do for Linux is to keep things simple for us. I am also pressing the
issue to allow options for selectable write-cache-tables to better assist
Andrea A's "elevator" and give Linux a basic performance boost that the
competition has over us because of total numbers.

Respectfully,

Andre Hedrick
The Linux ATA/IDE guy

-
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/



This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:15 EST