Messages in this thread | | | Date | Fri, 11 Aug 2000 17:43:46 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Linux 2.4 Status |
| |
Date: Fri, 11 Aug 2000 13:41:01 -0700 (PDT) From: Andre Hedrick <andre@linux-ide.org>
> Is there a good reason why we don't have the chipset tuning enabled all > the time? i.e., but another way, is there a downside to having it be > enabled all the time?
You haven't answered my question....
> It's nice if we can avoid situations where if users don't config their > kernels correctly with the right config options, their reward is a > trashed disk.... :-)
And this is any different than allow malformed data-phase services to block devices be the default because people at claiming igorance than to listen to facts? Sorry Ted, but this is worse than a missed drive timing.
Basically the old down side is that people bitch and moan and claim that I do not know everything and scream at a minor mistake while ignoring 1940's FATMAN in their face.
The 1940's FATMAN you presented looked real, thanks to some bone-headed disk manfacturers. Everyone recognized that. The discussion was over whether the proposed solution really solved the problem given that a hacker could always bit-bang the controller. It's also completely irrelevant to the discussion at hand.
You want it defaulted to always then we do so in the defconfig.
Until people begin believing me again, the only think I can do is give them options.
Ignoring non-technical issues, what are the technical reasons for the making chipset tuning be an option? I'm not saying that making it an option was wrong; I'm just asking what I hope is a reasonable question. Surely you had a reason for not just simply always doing chipset tuning? Were you concerned the code would sometimes get it wrong? Or were there other issues involved? I'm just trying to understand before I send a patch to Linus....
- Ted
- 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/
| |