On Mon, 24 Jul 2000, H. Peter Anvin wrote:
> There is a major problem with this: there is a number of devices which
> *require* vendor-specific commands to be issued, especially devices
> which have not been completely standardized yet (pre-SCSI-3 CD-writers
> is a somewhat obsolete example.)
These are OPS codes not COMMAND codes.
OPS codes are passed in known public SPEC - COMMAND codes.
This is the reserved space of DIAGNOSTICS in ATA-ATAPI devices.
> You're attacking this problem from the wrong end. If you have the
> opportunity to change the devices, what you should do is specify,
> plain and simple:
>
> * NO DEVICE SHALL PROCESS A COMMAND THAT MAY RESULT IN THE DEVICE
> BECOMING PERMANENTLY INOPERATIONAL.
Good then let them lock the areas that need to be lock.
Does every one think that I am so stupid to allow BS to happen that will
harm Linux (specifically create hardware problems for Linux)?
> In other words, the firmware on the device should report an error,
> reboot, power off, or go into safe mode until power cycle. It puts
> the onus where it belongs -- in the firmware of the device, which is
> ultimately the only thing that can guard against these kinds of
> failures.
>
> In particular, firmware upgrades should be cryptographically
> authenticated. These days, the overhead of doing a cryptographic
> signature is trivial even for a small embedded processor. There isn't
> an excuse anymore.
The bitch and scream over a $0.01 per drive addition.
$0.01 * 1.5e7 * number of models per year == MILLIONS per company.
This is what pisses me off the most, people dictating to me about what
they general have proven to know little or nothing about.
Sorry Peter, but I a really raw with this subject.
Please I am going to go get some sleep for two days, please go ask anyone
else here for help because they know all that I know.
Good night.....
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:18 EST