> On Tue, 11 Nov 1997, Andre Derrick Balsa <andrewbalsa@usa.net> wrote:
>>
>> And now a more practical reason: you are adding yet another option to
>> Mike's patch :-( Mike himself has stated that he did not mean to have
>> as many options in a future version of the patch.
>
> This is not a real good argument. Most of the current options can
> disappear, as the granularity is unnecessarily detailed. So we remove
> several, and put one back - so what if that's the one that gives a
> significant performance gain!
I think many of the present options could go without a fight (such as
SUSP_HLT, FAST_IO, NOLOCK and BTB); they should pretty much always be on,
yesno? What about the option WTALLOC, anyone know if this is helping or
hurting? As for VLFB, I don't know if that should be something we do in
the kernel. I am partial to "all-or-nothing" settings in the kernel, and
the VLFB one seems like it might require some extra tuning. Plus, it's
only good while in a graphics mode, right?
> Also in view of your post "Cyrix patch maintainer" I'd like to summarize
> my point of view once more, and then I'll shut up :-)
>
> 1. First priority is that a Cyrix patch makes it into the kernel to take
> care of the basic recognition of the chip, works around the identified
> bugs, enables suspend on halt, and calibrates udelay correctly.
Sounds smart to me.
> 2. Secondly, and as important: the patch should be perfectly safe, so
> for instance no VSPM.
Perhaps. I'm not too sure I know which cases VSPM is causing trouble for.
I've been using it for ages without a hiccup. I hear there are some
documentation s