Why modules in embedded Linux

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As the topic suggests, what is the rational behind using modules when it comes to an embedded Linux application.

Hardware is fixed as a result the drivers required for the hardware would be too. Are there some memory advantages? I'd imagine you'd use a little more FLASH for storing the individual modules rather than one large kernel with everything built into it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Correct, modules are a bit bigger than compiling it into the kernel.

But for some stuff modules are needed, for example the different USB gadget drivers, where you only can have one loaded at a time.

I have also noticed that the snd-at73c213 driver will sometimes fail to sync MCLK and bitclk, and it is easier to modprobe -r and modprobe again than to reboot.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also it means you can rationalize the size of your actual kernel image. This gives you greater flexibility in the placement of your binaries (for example storing uImage on a small memory device formatted in such a way as uboot can talk to it but having your primary rootfs on something more involved). More importantly though, it can reduce kernel boot time. Sure it takes longer to get full functionality because you'll probably have to go through and modprobe lots, but at least by that stage you can, for example, display splash screens, run startup jobs in parallel, start system monitors etc.

That being said, for my own purpose I always use monolithic kernels. I don't have any uses which require modularity and my kernel is small enough that boot times with everything compiled in are still sub-2s.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... at the price of boot time. I compiled buildroot with all I could in the kernel, and the NGW100 boots in about 2 seconds to the shell prompt...

I also question the module idea myself... If you have overlapping features of course it makes sense.. but for core feature, I really don't see the point.. The bandwidth of the storage is usualy limited, and it's a lot better to be snuggly compressed with into kernel with the rest than having to generate countless file system access to eventualy load the code that is needed.

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the responses, I think I'll stick to a monolithic kernel with the NGW100 development and not worry about using modules. I'll just build into the kernel what I need and also leave the module support out of busybox too which should reduce the code size even further.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also note that modules can be slightly slower because they are loaded into translated memory and therefore take up a bit of TLB real estate.

In general, if you know exactly what you want, you're better off compiling everything into the kernel. But on a development system, modules can make life a lot easier...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

buserror wrote:
... at the price of boot time. I compiled buildroot with all I could in the kernel, and the NGW100 boots in about 2 seconds to the shell prompt...
Now that's seriously impressive. We're talking from power-on, through uboot, up through the kernel, all startup items to a prompt?

As I said earlier, using modules can help boot time depending on where you define the 'booted' point.

Of course the boot time savings are during the loading (while the '...'s are being printed to the screen) so just testing the kernel startup time to prompt is misleading.

-S.