Re: Referring what kernel-images to build to the technical committee?
On Thursday 26 April 2001 18:19, David Schleef wrote:
> > 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.
So a 386 compiled kernel can still support MMX, 3DNow! and MTRR? In that
case we only need a 386 kernel, but it might be nice to have a PentiumMMX
compiled kernel as well (that should give better performance on all brands of
CPU that are better than 486).
> > (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.)
I am thinking of the various IDE options for dealing with broken drives and
controllers, PCI Quirks, etc. These things will break some machines when set
one way and break other machines on the other setting.
> 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.
So we ship half the kernel as binary and compile the other half after
installation? Sounds terrible. Why not just compile custom kernels for
every user?
It wouldn't be that difficult to write a script that asks a dozen easy
questions, checks the /proc data, and then compiles an optimised kernel.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Reply to: