XPost: comp.os.linux.development.system   
      
   In comp.os.linux.development.system Aragorn    
   wrote:   
   | On Thursday 29 January 2009 03:33, someone identifying as   
   | *phil-news-nospam@ipal.net* wrote in /alt.os.linux.gentoo:/   
   |   
   |> In comp.os.linux.development.system Aragorn    
   |> wrote:   
   |>   
   |> | Disabling the ability to load a module would automatically forfeit the   
   |> | use of the machine as a workstation, given that most video adapter   
   |> | manufacturers provide their drivers as modules, and particularly so for   
   |> | the proprietary ones.   
   |>   
   |> But this doesn't necessarily need to happen.  One can build a kernel with   
   |> all the drivers that come in the main source tree, or as source patches,   
   |> statically linked.   
   |   
   | Yes, but you were speaking of a kernel in which the loading of modules is   
   | *disabled.*  So what would you then do with your proprietary, binary-only   
   | nVidia driver module?   
      
   What I am looking for is a distribution that builds a "module free" kernel.   
   If I wasn't clear before, what that means is a distribution that rebuilds   
   the kernel so that module loading is not necessary, and all drivers for the   
   target install machine are built-in.  It does not mean module loading is   
   disabled.  But it would mean that any kernel level driver support for the   
   video card would be built-in.  And that means not using proprietary drivers   
   in module-only form, even though the user could reconfigure to do that after   
   the kernel is built, probably without rebuilding the kernel.   
      
   The focus is on how such a distribution would configure the kernel it builds   
   as part of the installation process, including what options it gives to the   
   user, how it presents this, and what automatic configuration it may use.   
      
      
   |> | *[1]* A monolithic kernel is not the same thing as a kernel with all   
   |> | drivers it needs compiled in-line with the kernel.  Even if Linux is   
   |> | built modularly, then it is still a monolithic kernel, because that's   
   |> | how it was designed.   
   |> |   
   |> | A monolithic kernel is a kernel in which virtually all drivers run in   
   |> | kernelspace, whether they were loaded as modules or built into the   
   |> | kernel image itself, as opposed to a microkernel, where the kernel only   
   |> | takes care of memory management and process scheduling and only has   
   |> | hardware support for the underlying processor(s), memory controller(s)   
   |> | and chipset, or an exokernel, in which the kernel only supports the   
   |> | processor(s), memory controller and some of the chips, but leaves memory   
   |> | management and all other hardware access to userspace.   
   |>   
   |> This is the term multiple people have used for designating a kernel which   
   |> has all the drivers it needs compiled in.   
   |   
   | Yes, but then again people are quite happily using erroneous nomenclature   
   | for just about everything, and I find that any attempts at explaining the   
   | correct verbage to them rapidly leads to aversion. :-)   
      
   The English language is full of bad and erroneous nomenclature.  I have   
   learned as early as high school to just "go with the flow" and use what it   
   is that other people use, if you want to be understood.  In cases where there   
   are some people that know one term, and others that know another, you just   
   have to figure out who knows which.   
      
   You can push a specific terminology of your own.  For example, I have tried   
   to push the term "cetal" to refer to base-16.  It really isn't necessarily   
   right or wrong.  But it's root ("cet") is a commonly used Latin derivative   
   used for 16 carbon chemical compounds in the same way "oct" is used for 8   
   carbon chemical compounds.  It has a historical meaning for 16.  But no one   
   has adopted it, so I have to use what the world uses.   
      
      
   | For instance, people say "X Windows" instead of "the X Window System", they   
   | say "folder" instead of "directory", they talk of "dimensions" as if a   
   | dimension were a plane of existence/reality instead of a vector in a   
   | coordinate system, they say "tremolo" when they should say "vibrato" - for   
   | those of you familiar with electric guitars ;-) - or Apple users typically   
   | refer to /x86/ as "the PC", suggesting that a MacIntosh isn't a PC, and   
   | ever so on... :-)   
      
   Go with the flow unless you have the means to change everyone.   
      
      
   |> What would be a better name to work on getting people to use, instead?   
   |> Static kernel (as opposed to dynamic kernel)?   
   |   
   | Close... ;-)  The generally accepted name for it is "a statically linked   
   | kernel", and the drivers in such a kernel are called "in-lined drivers" or   
   | "statically linked drivers". ;-)   
      
   What is the short descriptive term, as opposed to the articulated term?   
      
      
   | Note: With regard to your earlier posts on the subject, there is an option   
   | "allyes" to the GNU /make/ utility for configuring your kernel with all -   
   | and I do mean *all* - officially supported and GPL'ed drivers statically   
   | linked into the kernel.  Typically this is used only for testing by the   
   | kernel developers themselves, though.  Similarly, there is also an "allno"   
   | option.   
      
   Sounds extreme.  But I guess the kernel is past its image size limitations   
   these dats.   
      
      
   | Still, while this may seem like a shortcut for skipping the configuration of   
   | your kernel, it isn't, as there are lots of aspects to the kernel which   
   | require platform specific settings, e.g. interrupt timer frequency (depends   
   | on the number of logical CPUs you have and how the system will be used),   
   | kernel preemption support (and what level of preemptibility you want, if   
   | any), APM vs. ACPI, flat memory model (cfr. pre-i7 multisocket   
   | Intel /x86-64/ machines and all consumergrade /x86-32/ machines) versus   
   | ccNUMA (cfr. multisocket AMD /x86-64/ machines and certain (rare)   
   | Intel /X86-32/ serverboards) and in that case, with either sparse memory   
   | model or discontiguous memory model (kernel-specific, not   
   | hardware-specific), PAE, non-PAE or /NOHIGHMEM/ on /x86-32,/ stack smashing   
   | protection or not, SELinux support or not, and then not even to mention the   
   | processor brand- and type-specific optimizations, et al.  (Stock   
   | distribution kernels typically use generic /x86/ instructions, which   
   | forfeits site-specific optimization.)   
      
   Of course.  And how is the kernel a given distribution installed configured   
   with respect to these settings.  They made a choice somewhere even if it is   
   the kernel they built and packaged as a binary.   
      
      
   | So you see, you could garner a lot of information regarding the hardware   
   | from using a very generic modular kernel and possibly then, if you're a   
   | really good coder, use some scripting magic to translate that information   
   | into kernel configuration options, but there still are many kernel   
   | configuration options which really /are/ site-specific and are to be set or   
   | unset at the sysadmin's discretion - kernel preemption for instance, but   
   | there are others - and it would be very hard, if not impossible, to use a   
   | generic automated set-up for that which would then be usable across   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)