Messages in this thread | | | Date | Mon, 24 Jul 2000 00:09:57 -0400 | From | Chris Kloiber <> | Subject | Re: What's wrong with IDE patch and what proper solution shouldbe... |
| |
Steve VanDevender wrote: > > 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 > hardware. > > 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 > drives. > > Of course, there was the good point that despite all the hullaballoo, no > one has actually confirmed that you can destroy drives this way.
I know it's true. I have run the disk-destroyer program. Twice.
I compiled a 2.4.0-test5-pre2 kernel with an earlier version of Andre's patch and actually ran the disk-destroyer program as a test. Andre specifically did not include the fry-your-drive codes in the test program, but on the first try it sucessfully hosed the MBR and partition table (my /dev/hda1 was/is swap, so I don't know how much of that went bye-bye too). After a fresh install of Red Hat 6.2, I (glutton for punishment that I am) recompiled 2.4.0-test5-pre2 with the latest patch (has it been restored to www.kernel.org?) and now my system can survive the disk-destroyer (The drive still makes god awful noise when run, but no permanant damage occurs). I captured the output of the disk-destroyer and sent it to Andre with a list of my hardware (mobo & drive models) so he could further refine the patch. I wish more people would get off their high horses and help out in any way they can. I am a lowly installation support technician an not a kernel-god who dreams code in their sleep, but I will help in any way I can to improve Linux as a whole. Will you?
Chris Kloiber
- 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/
| |