To get more people to be able to use Linux, things such as installing drivers, updating the kernel, and general fixes needs to become way easier. That's the only thing that is better on windows, the fact that you can install a driver by double clicking an EXE files. I don't want to recompile my kernel every time I get a new piece of hardware. Why don't they make drivers RPM or DEB based? Wouldn't it be great if you could APT-GET your drivers? I have sound problems with ALSA and 2.6 kernels with my soundcard, the only way to fix it is to download drivers, and recompile the kernel. Sorry, but it is just easier looking elsewhere (to another distro).
My Website: http://ttgale.com
My Website Uptime: http://img.uptimeprj.com/holastickbo...dee9bae2e2.png
My Server Specs: AMD Athlon X2 3800+, 2gb DDR2 RAM, 1.5TB HDD, Ubuntu 9.10
My Gaming PC: Intel Core 2 Duo 2.93ghz, 4gb DDR2 RAM, 9800GTX+
beez, any precompiled drivers can just be inserted, alot of OEM put out linux drivers like this you basically run a shell script and BAM its in place. NVidia for example. 'sh NVInstaller.sh' accept the license and your driver is inserted into the kernels module directory ready to be modprobed and used (No recompile and certainly no rebooting like in windows.)
Zen is right, dynamic module loading is one more thing to love about Linux. Insert the module for you kernel into the module directory, modprobe it, done. No restarting, you don't even have to log out and log back in, I think I did have to scratch my nose once but that is entirely optional (your nose, not mine). Usually the module needs to be compiled for your specific kernel version but most installers automatically do this for you.
Sure you can recompile your kernel with the driver built in, but then you have to do it all over again when you update. Hardware I am almost completely certain I am not going to change or update I usually compile into the kernel. Everything else is a module.
The only thing I am not sure about is if there is a performance difference between running mostly modules or compiling everything in. Anyone shed some light on this?
Hi y'all.Originally Posted by beezlebubsbum";p="2818
Linux is Linux, if the drivers are contained in the kernel it's a recompile. Either that or download a binary kernel, but it's going to have drivers for a lot of stuff you don't need.
--glenn
I know you already know this stuff jro, but I'll give it a go in case it can help any foo'ers out there. ;-)
There are a few variables to consider when determining if a driver would offer the best performance gain if compiled in the kernel, or as a module. A few of these considerations would be:
* Processing power of the system.
* Total amount of memory available to the system,
* Amount of memory taken by the kernel and any drivers compiled with it.
* The kernel's need for the driver to be consistantly remain in memory.
* The stability of the driver itself.
* The time required, availability, or desire to compile kernels and modules when updates are needed.
There are advantages and disadvantages to compiling everything in (not uneccessary drivers of course, only those that the system can use) versus having all the drivers as modules.
As mentioned, one of the benefits to using modules is that the driver can be loaded dynamically as needed. So, for example, a USB key used on occasion can have necessary drivers loaded as modules when a user plugs in their key, but when a USB key isn't being used (and assuming no other USB devices such as mice or keyboards are in use), the modules can be unloaded to free up the memory for other processes (possibly improving the overall system response if free memory is tight).
However, it does take time to read the module from disk and load it into memory, In that essence, it would actually take longer to initially access to the device due to that delay than if the module was already loaded to begin with. Of course, to cut hairs, by compiling the driver into the kernel it would take slightly longer for the system to boot, but side-by-side it would still take less time for a kernel with a particular compiled-in driver to boot than a kernel with the driver loaded as a module.
Aside from those drivers that are required, some can actually benefit the sytem if compiled into the kernel. Take for example the driver for a NIC in a desktop when the system is part of a network. If we know that at each boot the module gets loaded, and we won't be changing the NIC out anytime soon, that driver would be a good candidate for compiliing in with the kernel.
Other devices that are "hard-wired" to the sytem, such as hard drive controllers, video and sound cards, etc. could also be good candidates. What we don't want to do is waste our memory resources by compiling in drivers for devices or abilities that won't ever be used, or rarely if at all, and analyzing the needs of "part-time" drivers for other usable devices (such as PCMCIA on a laptop that's only used on ocassion for example).
That's where the fun can begin for those like to tweak their kernel, but keep in mind that as the number of drivers compiled in with the kernel increases, so does the size of the kernel. Therefore access time can increase as well, which can degrade performance on a system with limited memory and processing power.
With adequate memory a monolithic kernel can be fast, but one of the things I like about Linux is that we can play on both sides of this fence. By not constraining ourself to a purely monolithic kernel, yet having the drivers compiled in for the resources used on a constant basis, the system can still adapt to changes in devices by calling modules. Some may consider this a security concern (the ability to load a module into the running kernel), but for desktops and the various devices we keep hooking up to them, it's almost necessary.
Another thing to consider is that the more drivers that are compiled into the kernel, the higher the risk of boot failure. If there was a problem that prevented a module from loading, the kernel would fail to load the module but continue on. If that driver had been compiled in with the kernel, we might end up with a kernel panic on our hands instead of only a failed module-load.
From experience I highly recommend starting light, compiling in a few drivers at a time for the devices there is a constant need for, and testing between each compile to ensure that everything's working. If the system flakes-out or panics, then I have a much better idea as to what driver caused it and can focus on resolving the issue, or leave it as a module (or unused) and work on it later.
In the end, you'll have a kernel that's tailored and optimized to your system and can set back and take it all in... at least until the next driver or kernel patch arrives!! ;-)
dscribner
Very well put! I'm sure that will be helpful to a lot of newbs. That makes an excellent candidate for a KB article IMHO. To Module or not to Module / Module or Built-In. You should submit it.
--glenn
you do realize that the only real difference you are talking about in speed is reading the module off of the disk, right? the init procedures are called regardless of whether it's built as a module or not.
IMHO the only time it's advantageous to build as a module instead of built-in is if you want to add capability to you _currently_running_ kernel and don't want to reboot.
Posting Permissions
Reply With Quote
Bookmarks