# Module vs. compiled support for WiFi

## Quasimojo

I'm working on getting my Intel 5300 wireless adapter set up, and I find that people recommend kernel support be compiled as a module, rather than compiled into the kernel itself (please pardon any improper phrasing - I'm still pretty new to this).

I was wondering why that would be? I guess I always just assumed that driver support included in the kernel would be better than via module, especially since this is a laptop, where the hardware is not likely to ever change.

----------

## cwr

I had some problems with an Ath9k card and CRDA setting until I compiled

it as a module.  Seems a pretty rare problem, though.

Will

----------

## bobspencer123

I think this is usually recommended because you can add optional parameters to modules when you can't do this with built in kernel drivers. Some wireless chipsets, I think, require some module tweaking to work. But, if your device is working with the driver "built in" then I wouldn't worry about it.

----------

## rh1

Building as module also allows you unload and reload the module which can be beneficial at times.

----------

## depontius

You can apply module parameters when the driver is compiled into the kernel, but then they have to go on the grub (or lilo) command line, and I woudn't wonder if the syntax has to be slightly different, in order for the correct module to get the correct parameters.  In addition, if you're still at the debuggery stage, you can (almost) always rmmod your module, then modprobe it again with new parameters.  When you finally get your parameters set, they can be tucked into /etc/modprobe.conf, or some similar file, and it'll "just work" after that.

Last, but not least, you haven't said if this is a laptop or not.  Several years back I saw warnings that some wireless adapters start burning some level of power as soon as the module loads and initializes.  It was necessary to rmmod the module to completely eliminate its power burn.  I don't know if that's still the case, especially in these days of rf-kill switches.

The only solid reason I know of to build something right into the kernel as opposed to as a module is if it will prevent mounting your root directory.  Even that can be handled by a properly built initrd, except that building an initrd is a black art to most of us, so we use what our distribution ships.

----------

## etops

So I want to add an additional question to this thread;

What is the performance comparison of separating as a module vs keeping in kernel?

in this example as speed of wi-fi?

or in general like cabled ethernet cards, sound card modules etc.

----------

## dmpogo

I would advise to compile wireless driver as a module.   In my experience wireless cards to get stuck/hang from time to time and it is useful to have ability to reload the driver (which includes reloading the firmware). Also reloading wireless module may be useful for suspend/hibernationLast edited by dmpogo on Wed Sep 29, 2010 1:26 am; edited 1 time in total

----------

## depontius

As far as I know, there is no performance loss by using a module vs built-in.

----------

## etops

 *depontius wrote:*   

> As far as I know, there is no performance loss by using a module vs built-in.

 

and I forgot to add my question filesystems?

I always build them inside kernel because I thought this way it would have better performance. (and also not to get involved with initrd.)

----------

## depontius

Code is code, and once it's loaded, it's "in the kernel", AFAIK.  Maybe in the bad old days you'd have to worry about near and far jumps, and perhaps that would make modules accessed by far jumps, whereas in-kernel would be near jumps, and faster.  But those days are long behind us, especially with 64-bit.  Incidentally, "in the kernel" can be problematic, because a while back I read that once access to kernel memory exists at all, malware doesn't need to even load a module - if you can write into kernel memory you can put code there and establish an entry point.  Module and exploit on-the-fly.

That said, I generally build my filesystems into the kernel also, but out of habit, not for performance.  A few months back I got burned when I started trying to use an ext4 root filesystem.  I'd been wanting to play with ext4 for some time, and my stock kernel config had ext4 as a module.  When I built my new kernel, I just noticed that it wasn't blank, not that it wasn't built-in.  The new kernel would load, but not boot, because it couldn't load the root.  Had the Gentoo initrd somehow known that I wanted ext4 and included it in its modules, or had I built a custom initrd with ext4 included, all would have been well.  I've never bothered to try moving non-root filesystems to modules.

----------

## etops

 *depontius wrote:*   

> Code is code, and once it's loaded, it's "in the kernel", AFAIK.  Maybe in the bad old days you'd have to worry about near and far jumps, and perhaps that would make modules accessed by far jumps, whereas in-kernel would be near jumps, and faster.  But those days are long behind us, especially with 64-bit.

 

If it is the only case you are right. But what about process scheduling? Would the code take control more frequently in kernel? Or somehow modules have a tiny little bit less priority? That was in mind when I was asking. I couldn't find any information about in-kernel vs module. If anybody can confirm I'll be glad.

Let's say the performance is exactly the same. So how people choose one option over other?

kernel side is: You have all the code in one file, and no need of initrd when you use filesystems for root partition. Maybe eliminating first loading time of modules. That's it! (or is it?)

module side is incredible, you can compile new modules, new version of modules, use module parameters, etc.

 *depontius wrote:*   

> Incidentally, "in the kernel" can be problematic, because a while back I read that once access to kernel memory exists at all, malware doesn't need to even load a module - if you can write into kernel memory you can put code there and establish an entry point.  Module and exploit on-the-fly. 

 

That's a good point, one more score point for the module. 

If someone knows, or has sources please enlighten me? (or us?)

----------

## dmpogo

BTW in the old days when modules were invented kernel module handling was more flexible than now. Kernel supported not only autoinsersion of the modules when the devices was accesses, and also removed modules unused over some period of time. That was the major selling point for the modules over the time - to keep runtime kernel at its needed minimum.  The autoremove was abandoned.

----------

