> 2) I am not willing to include the XFree86 VLFB detection code in the
> Linux kernel source. I doubt Mike will do it either.
>
And I wouldn't want that to happen either - definitively not a good idea (and
I did not mean to suggest that).
> 3) Some users may want to add another ARR for an extra 3D video board,
> with the correct setup for texture RAM.
>
True. However, setting up the ARR for the main buffer would take care of
things "painlessly" for the vast majority of Cyrix owners, which is what I
would like us to achieve.
> 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 really would like to challenge us to do the absolute best we can while not shooting ourselves in the foot.
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.
2. Secondly, and as important: the patch should be perfectly safe, so for instance no VSPM.
3. The patch needs to achieve as much performance gain for the typical Cyrix owner as is possible, and if that means asking the user to figure out some value to be entered as a seperate config option, so be it.
Thanks. Willem Riede.