Messages in this thread | | | Date | Tue, 25 Jul 2000 19:37:02 +0100 (BST) | From | James Sutherland <> | Subject | Re: Direct access to hardware |
| |
On 25 Jul 2000, Michael Poole wrote:
> 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.
Such as? (Bearing in mind this should void the warranty...)
> 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.
Not the case. I said there are ways to avoid the need to reboot on mission-critical systems.
> 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).
There are reasons to filter these commands out under normal circumstances, as Andre has explained. There are also probably exceptional circumstances where you would want/need to bypass this - for a repair/diagnostics disk, for example.
> 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.
It's not a case of talking "extensions", just a matter of preventing access to the vendor-specific commands which potentially void the warranty.
Anyway, Andre has now rendered this argument academic: the drive should now enforce these limits, logging any violations in case of later warranty claim. A much better solution, I must admit.
James.
- 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/
| |