Messages in this thread | | | Subject | Re: Direct access to hardware | From | Michael Poole <> | Date | 25 Jul 2000 14:11:34 -0400 |
| |
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/
| |