On Thu, Apr 26, 2001 at 04:15:15PM +0200, Russell Coker wrote: > On Thursday 26 April 2001 09:05, Andreas Metzler wrote: > > _Afair_ it is necessary to run a k6 (or athlon) "optimized" kernel to > > use 3DNow! in applications like xmms or lame. This probably applys to > > ISSE, MTTR and MMX, too.
This is not correct. > There is software available which only runs with MMX. We should offer a > kernel with MMX support which requires Pentium-MMX to support running this. > > For 3DNow! we should have a kernel which supports it. All kernels, even if compiled with CONFIG_M386, will support MMX and 3DNow. It just won't use memcpy_mmx() or memcpy_3d() as the implementation of memcpy(). The important part is saving the correct number of FP registers, which is done. > There is no need for a MTTR specific kernel. Right. You compile kernels with CONFIG_MTRR=y, and the kernel will detect if the processor supports it at run-time. > (I am sure that I could find a list of a > dozen boolean options which are all needed to be in one state or another for > various broken hardware - we can't provide 2^12 kernels). If you were to report this as a kernel bug, it would probably be fixed quickly. i386 CONFIG_ dependencies are designed reasonably enough that you can expect to build one kernel that runs on most hardware (apart from non-arch driver issues.) > Also I think that we should have an SMP kernel in the list. We could have one kernel with CONFIG_SMP=y. It doesn't conflict with other things, although this is an option that is likely to be on your list above. CONFIG_M386 is one as well, since the kernel can't use the better locking primitives that appeared in the 486. I'd like to see a single binary kernel (or two, because I'm suspicious about CONFIG_M386), and an easy system that allows you to build one of a set of standard kernels, i.e., a kernel that has everything enabled as modules, but varies in optimized processor, SMP, high memory support, etc. In particular, I don't think it's appropriate (in the idea I'm describing) to present the user with questions such as "Do you want APM support?" -- compile it in or as a module, and figure it out at run-time. In fact, most of the options could be auto-detected from /proc/cpuinfo. It could also be useful as a hardware tester at install time: "Would you like to test your hardware (and get a kernel custom build for your hardware at the same time)? This process will potentially take a long time." (Yes, I realize this idea is a bit crazier than average.) dave...