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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:26 EST