Hi all!
With this mail I'm going to try to accomplish a good thing(tm) - hopefully
I'll succeed. :)
In this mainly-IDE-thread there have been at least two facts stated (or
discussed) and I've got some comments on them. (Woohoo!)
1. It is possible to write software that will damage hardware.
--- Why is this? Simple; it adds functionality for the end-user. The manufacturer of my modem has made it possible for me to upgrade the firmware of the modem by running software from their website. I, as an end-user, think this is really neat. I bought a top-of-the-line 28k8 modem in '95 which is still top-of-the-line five years later, thanks to a couple of firmware upgrades. However, this functionality also means shit can happen that will cause my modem to be useless. (..turned into a brick.) This could be because of a power-fail situation right when I'm sending out the new firmware to my modem, or by my kid brother throwing a ball into the computer room, hitting the serial cable causing it to glitch for a millisecond or two. I can protect my modem from both of these things, but at what cost? I'd have to get an UPS for my computer/modem because I want to upgrade my firmware in MS-DOS and I'd have to lock the door to the room where I keep the computer. I'm not going to buy an UPS just because I want to upgrade my modem. Instead I'm going to risk the FlashROM being destroyed or only half-updated. I feel comfortable with this because I know how to take apart the modem and replace the ROM, but if I hadn't known that I would instead have wanted the manufacturer to add some sort of mechanism to the upgrading process that would withstand even a power outage. This can of course be done. (By downloading the new firmware to a temporary memory in the modem and then programming the FlashROM from that temporary memory, the entire modem being backed by neccessary batteries (or whatever) to make sure that the programming process will finish before the modem shuts down in lack of power.) However, I also realize that this would be pretty costly for the manufacturer to do and therefore it's (unfortunately) not all too likely to happen. Likewise I would like the manufacturer of my IDE drive to do their utmost to make sure that my IDE drive IS forward-compatible AND at the same time not a reason for headache. This could eg. be accomplished by the spoken-of jumper, that when enabled will allow updates of the firmware. Furthermore that update should of course take place in a manner that cannot easily cause the IDE drive to become useless. (Brick, again.) If this is not possible I would want an IDE drive that doesn't have any firmware updating facilities, or, perhaps more likely, I wouldn't want an IDE drive at all. Bottom line: Since we want to be able to upgrade firmware in hardware units, we have to accept that this can be done. However, what we shouldn't accept is that it can be done by anyone. (Someone we don't want to have on the inside of our computer casings.)2. The Linux kernel can be changed into just about anything root wants. --- Why is this? root is god in the system. And if I wouldn't be god in my Linux system, I'd probably still be running that-other-OS developing VB applications. This is however not the case. This is one of the things I like very much about Linux. Linux is sitting there in front of me, and I'm free to grab the chainsaw and start taking away features/bugs/stuff I do not need or do not want. And I know how to do this as well, because I'm a good god; I know C and hacking. This is what I feel about the IDE driver imposing restrictions on what will be sent further down the chain to the IDE harddrive: If I issue commands to the IDE driver that are either * not documented by the standard, or * prohibited by the standard I of course expect the IDE driver in the kernel to not accept them, just as I expect my modem above to not accept undocumented/prohibited AT-commands. (Maybe their real name is 'Hayes-compatible commands', I'm not sure.)
I've realized I'm not clear about whether that command sequence causing the IDE-harddrive to fry was allowed by ATAPI or not, but I don't think it matters too much. If they aren't, the thoughts above applies and the patch SHOULD be included. If they are valid (protocol-wise) it's really not a smart/good protocol. A harddrive shouldn't come with a self-destruct button imho. :)
The patch CAN be very good if I make a typo whilst hacking and accidentally send out the dangerous commands to the IDE-harddrive. If this is a good enough reason for Mr. Torvalds to include it into the kernel is not up to me, but it's definately a good enough reason for appreciating the patch.
And when it comes to /dev/kmem and all the fun stuff you could do with that, I think that it should be considered another story all together. It's a different way of hardware<->application communication than through a hardware driver in the kernel. The hardware driver is cooked and should be to any extent useful in all contexts of usage. The "raw IO driver" that /dev/kmem is really shouldn't be too neccessary in everyday use. If you need it you could load it as a signed module or something like that. If there isn't any vital use for it I'd even go as far as to disable it completely in the kernel if I want to raise the safety level. It could eg. be used to update the IDE harddrive firmware, by some update-application I got from the harddrive manufacturer. During the updating process, my harddrive is of course as fragile as my modem was in the updating process described above.
Closing words: Please, Mr. Hedrick, don't let almost-everyone's bitching at you put you down in your work. Code is better than no code. Especially if it does good things(tm). And since we are in the land of Open Source, we can choose not to use it and risk our hardware.
Bye!
(Ouch, it's 9:15am and I'm still up. Please excuse any insanity in this mail caused by insomnia.)
//Peter
-- irc: CareBear\ tel: +46-40-914420 irl: Peter Stuge gsm: +46-705-783805
- 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 : Sun Jul 23 2000 - 21:00:18 EST