XPost: comp.os.linux.development.system
From: user@example.net
phil-news-nospam@ipal.net wrote:
> In comp.os.linux.development.system J.O. Aho wrote:
> | phil-news-nospam@ipal.net wrote:
> |
> |> | There is no automatically detection of your hardware and selection of
> |> | modules/build in drivers, you can either use the default configuration
which
> |> | will be like any other kernel you get with a all the binary
distributions, a
> |> | kernel that has drivers for things you don't have.
> |>
> |> But the drivers are not all loaded. That's what a modular kernel is for,
> |> so you don't have to load everything.
> |
> | There is no point in loading SATA drivers if you only have a Via MPV4
chipset
> | which hardly do support ATA66. So no point in loading all the stuff you
don't
> | need.
>
> Right. If you don't have device FOO you don't need driver FOO.
>
>
> |> | meta-distributions let users to use the "make config"/"make
menuconfig"/... to
> |> | decide what they want in their kernel.
> |>
> |> Which is fine. But a distribution could be made to give the user a
monolithic
> |> kernel. It might well be argued that a user who isn't up on deciding
what to
> |> have in a monolithic kernel should not be choosing to have one at all.
But it
> |> is possible for someone to make a distribution that intends to make
monolithic
> |> kernels for some reason.
> |
> | You have the draw back with generic monolithic kernels that they will be
large
> | in size, as you don't know what the end user will have, will it be an intel
> | based or amd based machine, which graphics card will the user have... and
not
> | all drivers are part of the kernel tree, for example nVidia drivers, users
> | with nVidia graphics would be suddenly forced to use vesa and no 3D
support.
>
> I'm hoping, and expecting, that a distribution that focuses on monolithic
> kernels does not attempt to build a generic one for a wide range of PCs.
> What I might expect from such a distribution is its developers decided on a
> particular way to get a kernel configured, and build one. My curiosity is
> just how they might have chosen to do that specifically in the context of a
> distribution install intended to install a monolithic kernel.
They don't as you don't know what a user will be using his/her kernel and the
usage of the kernel can change, for example someone has just bought a
computer, the person has a single hard drive, no poin in using RAID here, so
assume they make a monolithic kernel without RAID support, a couple of months
later when the person has enough money, buys a second hard drive and decides
to build up a small RAID 0 for better disk speed, but no, his monolithic
kernel don't support that.
On the other hand, the it could be the other way around, the distribution
builds in RAID support, but the user will never use it, in this case the user
will waste memory on something he/she never will be using.
Modular kernel gives you the option to do both, allow those who wants to have
a feature to get it and let those who don't save memory.
What about updating a driver, the sound card you are using, is badly supported
in your monolithic kernel and there is a new driver released for it, which
means you need to rebuild the whole kernel. To start using the new driver, you
must reboot (don't this sound familiar from an American operating system?)
Modular kernel allows you build a module, replace the module file, unload the
module in memory and then load the new module, and you have updated the driver
without the need of spending time to building a big kernel and no reboot.
> | The optimal for a distribution is to make a modular kernel, where you have
> | only the most important things built in and modules are in a later stage
> | loaded depending on hardware on the users computer and you get a smaller
> | memory usage too.
>
> But ... the kernel being _installed_ to boot up on THAT machine is the point
> of interest. All the major distributions do install a modular kernel from a
> binary copy.
Yes they do that, even Apple has a modular kernel even if they have more or
less one version of hardware to support, it has a big advantage over a
monolithic.
> My interest is in the rare (if not non-existant) distribution
> that tries to install a monolithic kernel, whether the ability to insert
> other modules is, or is not, enabled.
If there is a such distribution, it's so specific fo the hardware, it's ment
only to run on that hardware and the hardware is quite limited, but the
general population of this planet don't install their own choice of
distribution onto their TV, DVD player, Phone and so on.
> For a distribution to do that, it has
> to make some choices about how it will go about having a compiled kernel
> configured. I want to see how THAT distribution would make such a choice
> and the end results.
First of all, people would not choose to use it, as it would imply the
distribution has a long install time (build the kernel) and that you won't
know if it will support what you install next on your computer.
The idea has been dropped many many many years ago as it is just bad and you
don't really gain anything, the only advantage you can get with a kernel which
has everything you need at boot time then you don't need to load an initrd
image and you can save a little in memory imprint and kernel size, but for a
distribution it's not possible to be flexible and drop the initrd image.
I think Aragon has already told you all this and a lot more.
--
//Aho
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
