What SHOULD go in the kernel
Dick Dunn
rcd at ico.isc.com
Fri Oct 20 08:01:05 AEST 1989
jfh at rpp386.cactus.org (John F. Haugh II) writes:
> ...pplacewa at antares.bbn.com (Paul W. Placeway) writes:
> >...Also,
> >most kernels won't do VM on themselves (for several _good_ reasons
> >:-) ),...
> ... discouraging paging
> the kernel is kinda wasteful the way kernels keep bloating.
Gack. John is right that kernels keep expanding (rapidly!), and that it
does waste memory (real memory which costs real $) to keep all that dreck
resident. The kernels of the Brave New Open International World are going
to be FAT! More accurately, they won't be kernels even in any reasonable
stretch (!) of the term.
But do we have to accept that? For the problems caused by bloating
kernels, at least we can say the problems might be slowing the growth a
bit. I'm afraid that if you let the "kernel" page, you really open it up
wide--there's no reason to think twice about putting EVERYthing in the
kernel and turning it into another MVS.
Is there any way to induce a change in viewpoint? Why not change the
perception of the problem from "we need a way to handle an ever-expanding
kernel" to "we need to stop the expansion of the kernel." (Yes, I know, it
doesn't work quite that way--you need to restructure it dramatically and
throw large pieces OUT of the kernel.)
Also, since as John pointed out there's only part of the kernel that could
be pageable, why not call the non-pageable part "the kernel" and put the
pageable parts in something called "user-level code"? The only loss I see
in doing this is that there will be people who won't be able to stroke
their egos by calling themselves "kernel programmers". (Of course, they're
just the folks *I* don't want messing around in the kernel.)
--
Dick Dunn rcd at ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...No DOS. UNIX.
More information about the Comp.unix.wizards
mailing list