lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 24 Jul 2007 13:50:35 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Helge Hafting" <helge.hafting@...el.hist.no>
Cc:	"Andi Kleen" <andi@...stfloor.org>,
	"Uwe Hermann" <uwe@...mann-uwe.de>,
	"Matt Mackall" <mpm@...enic.com>, "H. Peter Anvin" <hpa@...or.com>,
	"Jonathan Campbell" <jon@...dgrounds.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Patches for REALLY TINY 386 kernels

On 7/24/07, Helge Hafting <helge.hafting@...el.hist.no> wrote:
> Andi Kleen wrote:
> >> Some people are putting Linux kernels in the "BIOS" (i.e. ROM chip) when
> >> using LinuxBIOS (www.linuxbios.org). It _does_ make a lot of difference
> >> there how big the kernel is. At the moment you can't do that with
> >> anything smaller than a 1 MB chip. But if people could use 512 KB chips
> >> because the kernel is small enough that would sure be a great thing.
> >>
> >
> > I'm sure it would be possibel to save a lot of text size. But I don't
> > think removing the relatively small CPUID code is the right way.
> > That is just a big maintenance issue for little gain.
> >
> Well - anyone compiling linux for BIOS usage is targetting
> a single machine.  So an ability to target a single machine is useful,
> i.e. run the CPUID at compile-time, put the answer in a constant/macro,
> let the optimizer prune the alternatives. :-)

we are using AMD64 + LinuxBIOS + Kernel (without acpi) + kexec to load
final kernel.
So we can use drivers in kernel for any media (SCSI, SATA, IB,...),
not like EFI need every driver re-porting. and We could use KVM in
kernel to load other OS if needed.

The problem is Kernel is getting bigger and bigger. and old Tiny
kernel is stopping at 2.6.18...

add CONFIG_TINY_KERNEL in the kernel to remove unnessceary workaround
and quirks...

YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ