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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:19 EST