XPost: comp.os.linux.development.system
In comp.os.linux.development.system J.O. Aho wrote:
| phil-news-nospam@ipal.net wrote:
|> In comp.os.linux.development.system Mark Hobley wrote:
|> | phil-news-nospam@ipal.net wrote:
|> |> Does it do all the configuration for you (aside from giving you the
option
|> |> to do it your own way), such that the monolithic kernel would be the same
|> |> as you'd get running a modular kernel on that machine, in terms of what
|> |> drivers and other options are in effect?
|> |
|> | You build your own kernel from the command line as part of the
|> | installation process.
|>
|> Build. OK. But what about configure. Does it figure all that out for you
|> AND do it as correctly as it would load modules on a module based kernel?
|
| 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.
| You need to check up things for yourself with tools like lspci and then a
good
| way to do is to remove unneeded things from the default configuration and
make
| some tweaks that you like and you have a kernel that will work fine for you.
Somewhere, somehow, the right modules get loaded. MAYBE that is a script
that runs lspci. Maybe the drivers are loaded but when they discover no
devices to drive, they unload themselves. There should be a list of what
modules remain loaded.
|> What I am looking for is how distributions go about presenting configuration
|> issues to the human doing the install. The ideal distribution would be one
|> that BY DEFAULT builds a monolithic (no modules) kernel without any user
|> interaction needed at all (besides maybe an option screen to choose between
|> monolithic and modular). One that requires the human to make all the same
|> configuration choices as they would have to do if independently building a
|> kernel from source is of no interest at all (because it adds nothing to the
|> kernel building process).
|
| 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.
| binary-distributions builds a load of common drivers and drivers needed by
| their major customers and you get those, no matter if you need them or not.
But they are not all loaded, or remain loaded, in the kernel.
| It feels like you are really thinking of system configuration tools that
loads
| modules, that works a lot differently than selecting what to build in a
| kernel, as you can't say for sure if module/driver X is the right one or Y in
| some cases, which leads to that tools like kudzu may try to load one driver
| and if it don't seem to load properly, then it's removed and the next one is
| loaded.
Those are issues that certain can exist. I would want to see how such a
distribution handles it. Maybe they just build the kernel with what they
believe your machine needs and let you revise that then or later. This is
part of what I wanted to see what someone else decided to do in this case.
--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
