> > b) They wouldn't work at all and would completely mess things up
> > (lock the machine, interfere with HD operation, I can't recall
>
> as with anything: PCI bridge optimization, 486+ features...
PCI bridge optimization will be moved to pciutils soon.
> I find that opinion shocking. It is easy to have multiple
> kernels with LILO and loadlin. It is easy to make a simple boot
> floppy with the new kernel. Screwed up kernels are no problem.
But if you want to find out which set of options is best for
your setup, it takes a lot of time to recompile the kernel as
many times.
> This isn't kernel bloat, since it could be freed at boot along
> with all the other one-time initialization code.
I vote for making it an option settable on the kernel command line.
So, what Cyrix-related things do we need to have in the kernel?
- Suspend on halt: Do we really need to set it up during kernel
boot? The example posted earlier mentioning system which died of overheating
before it reached the rc scripts doesn't seem to be important from my
point of view as it's certainly a HW problem and a machine suffering from
such problems won't go reliably anyhow.
- NO_LOCK (Coma bug workaround): Does anyone have a working solution
(Alan mentioned the original one broke some X servers)?
- VSPM: Probably not worth supporting as the performance gain is
almost unnoticeable.
The rest of Cyrix features seems to be solved cleanly by userland utilities.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "A professor is one who talks in someone else's sleep."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu