Re: Patches for REALLY TINY 386 kernels

["H. Peter Anvin" <hpa@zytor.com>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/