[lkml]   [2000]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: What's wrong with IDE patch and what proper solution should be...
Mike A. Harris writes:
> >Yikes! This way lies madness (at least for SCSI). Removing the
> >equivalent of the sg interfaces would reduce Linux to a platform much
> >like Windows where every single new SCSI device probably needs to
> >provide its own kernel modifications/modules/driver to allow
> >device-specific apps to talk to it.
> >
> >Right now, you can write (for example) an Iomega Jaz utility without
> >any kernel futzing at all. Contrast this with Windows where it seems
> >necessary to always install a new driver.
> >
> >Don't go there.
> Part of the kernel's JOB is to arbitrate hardware access. If we
> extend your argument, we take out all hardware drivers and
> replace them with userland applications and libraries. Then we
> end up with MSDOS.

Oh please. The point of a standard protocol is to make it possible to
interchange devices from any number of manufacturers on the same
interface. That way the kernel need have only a SCSI driver, not a
Brand X SCSI driver, a Brand Y SCSI driver, a Brand Z SCSI driver, ad
infinitum. We should have standard drivers to support standard
protocols, not a huge mess of drivers for all sorts of nonstandard

So apparently the story so far (as best as I can reconstruct it from
Andre's unrelentingly incoherent rants) is that some possible ATA/IDE
commands that aren't currently defined in the ATA/IDE specification have
been appropriated by some manufacturers to do certain very dangerous
things. Apparently these "can and may" (to use Andre's
self-contradictory phrasing) void your warranty if issued to the drive,
silly as that sounds.

I'm sure the manufacturers would love to blame all those OSes out there
for damaging their drives, when it's the manufacturer's own damn fault
that they've made drives that can be turned into metal-and-plastic art
objects with software commands. What if Intel said that executing
undocumented opcodes could void your warranty and destroy your
processor? Would we be putting code into the kernel to try to prescan
all executables for the self-destruct opcodes? No, the smart people
would be fleeing from Intel.

I think we need to find out which manufacturers were stupid enough to
make drives that can be made to self-destruct, and stop buying those

Of course, there was the good point that despite all the hullaballoo, no
one has actually confirmed that you can destroy drives this way.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.068 / U:0.916 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site