General linux kernel function question
 

I'm working on a project where I'm going to have several systems with nearly identical hardware, but the few variations there may be, I was wondering if I can tailor the kernel to work around this.

Primarily, my concern is that some of my systems will have ati video cards (not amd, ati) and some may have nvidia. Is it possible to compile totally different vendor gpu drivers into the same kernel?

Thanks!

Yes.

You can even sometimes load two of them, if both are installed. You can even have them compiled into the binary - though that can cause problems depending on the cards (they must not use the same shared memory, or control register addresses)

If you look at the configuration files for most distributions, you will see that they have all the common video card drivers selected. It is the system init that loads the drivers for the identified hardware. Usually loading is done in the initrd, though it can be delayed until after the real root is mounted and the final init program runs.

Stricly speaking, no, you can't compile the support into the kernel.
But you can use loadable modules - and an initrd isn't required for this, but is common.

So you need to know (exactly) what you really want before you can ask the question, and we can answer it.

Should be able to compile it in - just don't specify it to be a module. Granted it does make things a bit awkward for hardware changes... And there can be conflicts with multiple hardware installed...

I also acknowledge that it has been years since I compiled video drivers into the kernel.

Ah, now I'm thoroughly confused, every time I've gone to "install" video drivers in linux, I've needed the kernel source. That always said to me that if the source is needed, it's just compiling itself into the kernel. I suspect that is now not necessarily the case.

Modules exist independently of the kernel, yes? Does this mean I could have an ATI module and an Nvidia module that I could shuffle around onto the right machines?

Thanks for your help!

You can't compile non-GPL (proprietary) code into the kernel.
Accomodation has been made for firmware loading, but even that was hotly debated.

Previous post was in response to @jpollard - but yes, the modules are supplemental to (rather than "independent" of) the kernel, and yes you can have both present. Simply a matter of loading the correct one.

That sounds reasonable, but I think before I get in too deep, I should learn more about the linux kernel. Coming from windows land, I'm used to drivers for things being separate entities from the kernel, and you go to install them, and they sit in a folder somewhere, and get called when needed (or at boot or whatever) but the sense I'm getting from linux is that they're much closer to the heart of the OS, hence the need for compiling modules and the general level of depth when installing devices.

If I end up with a kernel module, is that going to be like a file, or a tar.gz that I could copy to a usb drive and move from machine to machine?

Windows programmer at work, Linux at home guy here.

For video cards you have two kinds of drivers: the open source ones like nouveau (nvidia), radeon* (ati); closed-source ones from nvidia and ati (the companies).

The "driver" portion of Windows/Linux is identical in function between the two kernels. Linux "probes" the hardware at startup to see which driver to load, or can be told which driver to load. Windows does essentially the same thing and will additionally offer to go download the "stock" driver for the hardware. The "stock" drivers are the ones that the respective companies have submitted to Microsoft for inclusion in the Windows install media.

So, the Linux kernel modules are (mostly) all of the drivers and driver support code for all of the hardware that Linux supports. On my Slackware Linux machines at home I have the full kernel modules installed, which includes open source drivers for both ati and nvidia cards, and the kernel handles figuring out which card I have and loading the correct driver.

Linux modules, or drivers, aren't really any "closer" to the kernel than are Windows drivers, generally speaking, it is just that they're more "exposed" to the user. This is a consequence of the difference between an open source OS and a closed source OS.

EDIT: On Linux the kernel modules (drivers) can be compiled into the kernel, compiled as "modules" where they're simply files in a directory, or not compiled at all, which means that that kernel/Linux installation would not support those devices for which the modules were not compiled. IIRC, kernel module file names end in .ko, so you could do a 'locate .ko' and figure out where they're stored. I'm at work right now and don't remember off of the top of my head.

should I be concerned with them being compiled into the kernel or not? is it a huge performance advantage or something? or is it just a different way to accomplish the task?

How do the open drivers compare to the closed ones?

Kernel modules (drivers, filesystems, encryption, network,...) are all files stored in /lib/modules/<kernelversion>/kernel/...

All modules have the extension ".ko" for "kernel object". They are compiled/linked to a specific kernel version (using the appropriate headers and system.map for the target kernel) such that the module can be loaded into the kernel memory, and connected to the kernel data structures so that they may be used.

Each of these could be linked directly into the kernel, but that would bloat the kernel a LOT and use up a fair amount of memory (well over 10 MB). Most modules are not in use on any given system, or even at any given time. The base generic kernel is usually about 5MB.

The advantage of modules is that they can be replaced, the active module unloaded, and the replacement loaded, thus the system updated without requiring a reboot. SOME modules can't be unloaded (they may be in constant use after they get loaded), which would require a reboot.

Performance wise, the only thing saved by compiling in is some boot time, which isn't all that significant. If all needed drivers are compiled in, then there is no need for the module loader either which saves some memory. I believe a number of embedded configurations use this just to eliminate the real need for an initrd, though that is still useful for storing applications for the embedded system.

As for the open source drivers vs the closed source drivers... the major difference is that the company providing the closed source drivers can put custom/proprietary functions in the driver. The Open source drivers won't have those, and sometimes (when the information is unavailable from the vendor) the driver has to be reverse engineered - which can take quite a while, and be very error prone. When the information is available, the open source drivers usually match what the vendor can provide, and it assures that the driver won't disappear if the vendor decides to stop providing the proprietary driver, or drops support for the board.

At the risk of getting yelled at - my goal is to have a machine that never changes. No updates, no new software. This will be a machine I configure once to do one thing and that thing will never change. Security is no concern to me for this application. Essentially, if compiling things into the kernel makes it boot faster and the key loss is modular upgrade-ability, that's an easy choice to make.

I wonder...then if I should just have two different kernels, because the video card will be the only thing that changes from machine to machine.

I have a whole boatload of research in front of me....I'm very curious to see how small I could make the kernel for my application.