Re: Referring what kernel-images to build to the technical committee?
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...
Reply to: