XPost: comp.os.linux.development.system   
   From: user@example.net   
      
   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.   
      
   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.   
      
      
   > 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.   
      
   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.   
      
   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.   
      
      
   --   
      
     //Aho   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)