XPost: comp.os.linux.development.system   
      
   In comp.os.linux.development.system Aragorn    
   wrote:   
      
   | What I was talking about however is the fact that you wish to start off with   
   | a statically linked kernel with all available GPL'ed drivers in-line'd with   
   | the kernel image itself, and as such, you would have /nvidiafb,/ /vesafb/   
   | and /radeonfb/ all in the kernel already, long before you start loading a   
   | proprietary and binary-only nVidia driver module.  So you may tell the   
   | kernel to use /vesafb/ by means of a boot parameter in your bootloader's   
   | configuration file, but the /nvidiafb/ code would still exist in the   
   | kernel, and might possibly conflict with any of the other framebuffer   
   | drivers, and will certainly conflict with the proprietary nVidia driver.   
   |   
   | In other words, to avoid those conflicts, you would have to build those   
   | GPL'ed framebuffer drivers as modules, so that only the required one is   
   | loaded into memory.   
      
   If driver A and driver B are in conflict, I would never build a statically   
   linked kernel with both of them present.  I would hope and presume a   
   distribution (if one exists or is ever made) that focuses on a statically   
   linked kernel would also not do so.  I would configure a kernel with just   
   one of the drivers to avoid the conflict.   
      
   A machine with 2 video cards that need both drivers that conflict would be   
   a strange problem, but not one I am interested in solving.   
      
      
   |> The way I udnerstand it, module loading can be left enabled, and that can   
   |> be used in those special cases where a module is the only practical   
   |> choice.   
   |   
   | Of course, but considering that you want to build _everything_ into the   
   | kernel, the conflicting framebuffer drivers would all be built into the   
   | kernel as well.  And when it's built-in, you cannot unload it.   
      
   Not I.  I have no intent to build _everything_ into the kernel.  I have   
   built statically linked kernels, before, and have never even given such a   
   bizarre concept the first thought.   
      
      
   | Yes, but again, some of the loadable modules could generate conflicts with   
   | the drivers built into the kernel image itself, or they could possibly   
   | generate conflicts with eachother, and then you wouldn't have any way of   
   | unloading the conflicting code, since it's statically linked into the   
   | kernel image.  This is yet one other reason as to why there are modules.   
      
   It would be a legitimate concern where a driver is available ONLY as a module   
   and conflicts with another driver being statically linked in.  The latter   
   cannot be unloaded.  The correct approach would be to not include the drivers   
   that conflict in the statically linked kernel, and ensure the kernel also   
   allows loading modules.   
      
      
   | I started learning English on my own account from watching British and   
   | American television series and movies when I was about six or seven.   
      
   So basically you learned a subset of urban coastal English :)   
      
   Even English has a significant amount of semantic overloading.  That   
   is words that have 2 or more meanings.  There are also some constructions   
   of sentences that can have 2 or more meanings even with single meaning   
   words.  Maybe I should start collecting these as I run across them.   
      
      
   |> |> 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.   
   |> |   
   |> | Yes, I come from a scientific education background myself and I   
   |> | understand what you're saying.  Nice touch, by the way. :-)   
   |>   
   |> I do use it in comments of my own source code.   
   |   
   | I don't think that's a bad idea, but given that this nomenclature is unknown   
   | to many, it might help to add a little note about what it actually   
   | means. ;-)   
      
   I do toss in "(hexadecimal)" in a few places.   
      
      
   | I will always explain things to people in terms that they themselves can   
   | understand, but I will also always it point out to them whenever they are   
   | using incorrect nomenclature, and why.   
      
   OK.  That seems fair enough.   
      
      
   | It's my own very little contribution to the further education of people. :p   
      
   It would be that slight nudge in the correct direction in the hope that if   
   there is any flexibility to move, it would not be in the wrong direction.   
      
      
   |> |> |> 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?   
   |> |   
   |> | Ehm.... "statically linked kernel". :p  Or "non-modular", if you want it   
   |> | shorter. :-)   
   |>   
   |> I'll use "static kernel" for now and see how that plays.  That's no more   
   |> or less accurate than "statically linked kernel" if one figures out that   
   |> it is about linking.  If module loading is still enabled, then technically   
   |> it is a "mostly statically linked kernel" anyway to account for a module   
   |> that can be loaded later.   
   |   
   | Or you could simply refer to it as a "non-modular" kernel.  I agree that   
   | it's tempting to say "monolithic", but since that concept has already had a   
   | meaning assigned to it, we must use something else. :-)   
      
   1.  A kernel with few drivers statically linked (mostly useless with what it   
       has), but does allow loading modules.   
      
   2.  A kernel with most drivers statically linked (and useful for many things   
       with just this set), but does allow loading modules.   
      
   3.  A kernel that does not allow loading modules, and thus is limited to the   
       drivers that are statically linked.   
      
   I see at least three needed names.  I think #1 and #2 need to be distinguished.   
      
      
   |> I'm looking at building something for embedded systems.  That is, of   
   |> course, quite a different thing than a "static kernel distro" for a hosted   
   |> system. If the "SKD" did have user input features, that might have ideas I   
   |> could use.   
   |   
   | Well, that certainly narrows it down now, because when dealing with embedded   
   | systems, you will almost certainly want to enable certain things in the   
   | kernel which might otherwise be up to the sysadmin's preferences in distros   
   | intended for servers, workstations or notebooks.   
   |   
   | I would of course imagine that the hardware you'd be developing such a   
   | distribution for is rather uniform as well, and rather specialized.  This   
   | does of course hold the risk that most of the drivers for such components   
   | could be available as proprietary code only.   
      
   Proprietary drivers certainly exist.  But the embedded system I built most   
   recently had all GPL drivers applied as a source tree patch, with a firmware   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)