Re: prune the images?

Jim Nance (jlnance@avanticorp.com)
Tue, 26 Nov 1996 14:57:19 -0500 (EST)

> > Holy cow: 9.1 MB /vmunix (THIS IS SUPPOSED TO BE A MICROKERNEL!!???)
> > If this is the price for a unified kernel, I am not sure it is a good idea
> > :^)
>
> While I wouldn't call myself a friend of Mach, in all fairness: DEC
> Unix is based on Mach 2.5 which is _not_ a microkernel. Mach 2.5
> started to lay the foundation for a micro-kernel but the actual
> microkernel was implemented only starting with Mach 3.0.

The /vmunix on a Digital Unix (or most any unix system) is also not
stripped (*). Its still fairly large, but its not nearly 9M of actual code:

scooter> size /vmunix
text data bss dec hex
2611696 371504 431744 3414944 341ba0

> I think a single kernel would be a good idea _provided_ that it would
> be a configuration option. Say, you could pick between "generic" and
> one of the real platforms. As long as picking a real platform will
> give you a kernel as performant/optimized as the current kernels,
> there is no reason not to do this (unfortunately the advent of the XL
> has made this task a bit more onerous, but it shouldn't be that bad).

Perhaps we could find a way so that you could specify which systems you
wanted the kernel to run on. That way you could get the equivalent of
generic by including everything. Perhaps the first step could be to make
a kernel that could boot via either SRM or Milo. I would not think that
that would bloat the code very much, and that would eleminate the particularly
annoying problem of having for example an Avanti kernel that won't work
on your Avanti.

Jim

(*) Does anyone know why? I used to think it was so ps could find data
structures in the kernel, but Linux used to have a kmem based ps and we
did not have to have an unstripped kernel. When I first started following
linux development, the big controversy on alt.os.linux was whether it would
bloat the kernel too much to have a system call for ps instead of just
hacking through /dev/kmem. Interesting how things progress.

--
To unsubscribe: send e-mail to axp-list-request@redhat.com with
'unsubscribe' as the subject.  Do not send it to axp-list@redhat.com



Feedback | Store | News | Support | Product Errata | About Us | Linux Info | Search | JumpWords
No Frames | Show Frames

Copyright © 1995-1997 Red Hat Software. Legal notices