James Sutherland <jas88@cam.ac.uk> writes:
> On Tue, 25 Jul 2000, Stuart MacDonald wrote:
> > You agree it's a hardware bug. Which implies it should be fixed. In
> > hardware. Not worked around in software. Sometimes, as with the
> > pentium bug, you do want to hack things, since doing so works
> > around the problem and Intel wasn't forth coming with a hardware
> > fix at first. No functionality was lost with the work around. Not so here.
> > Functionality will be lost.
>
> What functionality? Remember, only the commands which should NEVER be
> issued except as part of a low-level diagnostic or maintenance procedure.
> Since nothing should ever issue these commands anyway except the vendor's
> own software, no functionality is being lost by disabling them, except for
> that software, which can be adapted to work around that problem in a way
> which will also improve it significantly.
Bzzzt. Please take your continued wrongness to alt.flame. Perhaps
they will be able to remove your head from wherever it is stuck.
The only way to try to protect the hardware from the kernel is to
filter out *all* undefined (nonstandard) commands. These are not
necessarily just diagnostics or maintenance commands. They could be
vendor-specific power management commands. They could be commands to
make the drive kick in s00p3r-s3kr1t high performance mode. The
commands could be literally anything not described by the spec.
There are reasons for non-vendor software to talk to the drive, but
you continue to pretend there aren't. There are reasons to not want
to reboot just to use these extensions (firmware upgrade or
otherwise), but you continue to pretend there aren't. There are,
however, no reasons for the kernel to filter the commands it sends to
the drive only sometimes, but you continue to pretend there ARE (with
your compile-time option). Talking to the drive should be permitted
under Linux or it should not; you shouldn't have to switch on some
"firmware upgrade kernel" flag just to talk ATA extensions.
Michael
-
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:19 EST