Jonathan Campbell wrote:
> I wrote a set of patches out of concern that even if you compile a 386
> kernel a lot of code irrelevent to legacy machines still remains. Things
> like the Pentium TSC register, DMI information, ESCD parsing, and the
> use of CPUID do not apply to these machines, but looking at System.map
> you can see they're still there.
>
> Already with these patches I can compile a zImage kernel that is 450kb
> large (890kb decompressed) with a small initramfs payload, floppy and
> kernel module support, FPU emulation, that can successfully boot on an
> ancient 386 laptop with only 1MB of extended memory. Eventually what I'd
> like to have is the ability to compile a pure 386 kernel with all
> non-386 functions removed (and perhaps the same for 486 machines).
>
> These patches were written against the vanilla 2.6.21.1 kernel. They
> will have no effect UNLESS you make menuconfig and explicitly enable
> them there.
These should all probably depend on EMBEDDED (which is the "allow
features to be disabled which would be dangerous for most people".)
CONFIG_X86_TSC, however, would be cleaner implemented by something like:
#ifdef CONFIG_X86_TSC
int disable_tsc;
#else
#define disable_tsc 1
#endif
... then gcc will optimize out the rest of the code.
The CPUID stuff hacks up the code quite a bt which makes it hard to
read. Can you abstract any of that code so it doesn't get so ugly?
Stuff like:
+#ifndef CONFIG_X86_DONT_CPUID
if (cpu_has_fxsr) {
/*
* Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
@@ -1177,6 +1178,7 @@
set_in_cr4(X86_CR4_OSXMMEXCPT);
printk("done.\n");
}
+#endif
... is much better handled by forcing the value of the cpu_has_* macros
to zero, in which case gcc optimizes out the if clause. The current git
HEAD has handling of constant cpu_* going the other way, but it should
be easy enough to extend.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
