You are not logged in.

#1 2006-06-28 14:00:40

tomfitzyuk
Member
Registered: 2005-12-30
Posts: 89

Confused about kernels, ramdisks, modules, etc.

Hey,

I'm confused as to the purpose of things such as the kernel, ramdisks (initrd, initcpio, initramds, etc.) and modules.

Here's what I think I know:
Kernel - This allows communication between your hardware and your software. It's the heart of the OS.

Ram Disk - From what I can gather from the wiki, the ram disk is loaded by the kernel and stores the drivers for anything which may be needed to read the root filesystem. [Question #1: What are the advantages of using a ram disk? Why not just put all modules related to the root filesystem in the kernel image?]

Modules - A module is a driver for a particular piece of hardware, say, ethernet card, sound card, etc.
On Arch they are loaded by UDev which gets its list of modules to be loaded from /etc/rc.conf
[Question #2: How does UDev get the drivers? Does it store them? Get them from /usr/src/linux?]

So, everything needed to get a computer running is in the kernel image, everything needed to access the root filesystem is in the ram disk (which is initcpio now?) and everything else are modules which will be loaded by UDev?

EDIT: Also, assuming the kernel only has the drivers to get the system up, does this mean I needn't choose drivers for filesystems, sound cards, etc. when configuring my kernel using 'make kconfig' ? I then assume I edit mkinitcpio.conf to tell it what drivers I need to be loaded to access the filesystem, then I must run mkinitcpio to create this new image. Finally, I just edit /etc/rc.conf to load whatever other modules I need loading?

Thanks,
Tom

Offline

#2 2006-06-28 14:40:23

tomfitzyuk
Member
Registered: 2005-12-30
Posts: 89

Re: Confused about kernels, ramdisks, modules, etc.

Thanks to some guys on the IRC channel (Ethianen, mucknert & Sacro: thanks guy smile) I understand it now.

1. Putting all the modules what would be in the ramdisk, into the kernel would be inefficient since some of the modules in the ramdisk would never be loaded.

2. UDev gets the drivers from /lib/modules which is populated during the compilation of a kernel (make modules_install IIRC).

Here's the log of the chat in #archlinux if anybody's interested:

[15:49:50] <TomUK> So the kernel allows communication between hardware and software, initcpio loads drivers which are used to access the root filesystem (so, the drivers for ext3) and then Arch handles loading any other drivers?
[16:01:19] <TomUK> Does UDev get the drivers for the modules it's loading from /usr/src/linux?
[16:10:23] <Sacro> TomUK: i hope not
[16:10:42] <TomUK> Sacro: Where does UDev load modules from?
[16:10:50] <Sacro> AFAIK /usr/src/linux is depreciated
[16:11:03] <Sacro> should use /usr/src/linux-`uname -r`
[16:11:41] <TomUK> but it does load them from /usr/src/linux_whatever
[16:11:44] <TomUK> ?
[16:13:45] <Ethiainen> TomUK:  ls -ld /lib/modules/`uname -r`
[16:13:49] <Ethiainen> TomUK: from there
[16:14:26] <Ethiainen> TomUK: all *.ko are modules
[16:15:03] <TomUK> Are they created by 'make modules_install' ?
[16:15:12] <TomUK> which I assume is handled by the PKGBUILD for kernel26
[16:15:24] <TomUK> oooh I see
[16:24:56] <TomUK> So when I'm configuring a kernel with 'kconfig', everything that I mark with 'y' is included in the kernel image and everything I mark with 'm' is compiled as a module and put in /lib/modules
[16:25:26] <TomUK> Then, when booting, UDev looks at /etc/rc.conf, sees what modules I want loaded, looks in /lib/modules, [hopefully] find its and then loads it.
[16:25:54] <Ethiainen> TomUK: something like that yeah
[16:25:57] <TomUK> So why bother with a ramdisk (initcpio, initrd, ramfs, etc.) if UDev can load modules?
[16:26:38] <mucknert> Tom_Beers: BECAUSE udev won't be able to load modules for e.g. reiser4-support off a reiser4-partition.
[16:27:00] <mucknert> Erm.
[16:27:02] <mucknert> @ TomUK
[16:27:14] <TomUK> Oh I see, why not just include reiserfs support in the kernel image?
[16:27:26] <Ethiainen> TomUK: because ramdisk and the likes operates post system boot
[16:27:40] <TomUK> Not sure what that means
[16:27:42] <mucknert> You can't include each and every driver into a stock-kernel.
[16:27:56] <TomUK> What would usually go in a ram disk?
[16:28:43] <Ethiainen> TomUK: reiserfs, xfs for example
[16:28:57] <TomUK> Just the filesystem drivers?
[16:29:04] <TomUK> just the root filesystem*
[16:30:00] <Ethiainen> TomUK: a SATA controler could go into ramdisk i guess
[16:30:21] <mucknert> If you build your kernel yourself and customize it to your needs, you don't need a ramdisk if you know what you do. But compiling EVERYTHING in a one-size-fits-all kernel of a distribution would be just plainly stupid.
[16:30:38] <mucknert> Is that so hard to understand? tongue
[16:30:42] <TomUK> No smile
[16:30:44] <Ethiainen> hehe
[16:31:06] <TomUK> But I figured if my ram disk only had one driver in it, ext3, why not just include it in the kernel
[16:31:28] <TomUK> but now that you say that many drivers would be in the ram disk to satisfy many people, I understand
[16:31:32] <Ethiainen> TomUK: sure, make it in kernel
[16:32:04] <Ethiainen> TomUK: but why get, xfs, ext3, reiserx in kernel!?
[16:32:13] <TomUK> Well there's no need
[16:32:33] <TomUK> well, no need for xfs and reiser to be in the kernel, since I never need them
[16:32:54] <TomUK> I guess I could create modules for them incase I ever wanted to mount a partition of that filesystem
[16:32:55] <Ethiainen> TomUK: you never know, you could need to mount a partition with XFS
[16:33:04] <Ethiainen> TomUK: so, just pop up the module
[16:33:27] <TomUK> I see, so if you're creating a lightweight kernel you needn't bother with a ram disk?
[16:33:34] <Ethiainen> TomUK: or build a ramdisk with it if you need to boot it
[16:33:48] <Ethiainen> TomUK: no sir
[16:35:22] <TomUK> Ooh I think I fully get it now smile Ram disks are a good idea for distributions because the distribution must somehow support every filesystem a user might use. They can't do it through udev since they can't access udev, and they'd rather not do it through the kernel because that's inefficient.
[16:35:43]  * mucknert nods approvingly.
[16:35:56] <TomUK> thanks for the help guys smile
[16:36:05] <TomUK> I hated not knowing what the hell initrd did tongue
[16:36:35] <Ethiainen> TomUK: so now, you should go do some reading about kernel and ramdisk, and boot process
[16:36:50] <Ethiainen> TomUK: and then some practical testing tongue
[16:37:16] <mucknert> TomUK: Shall I paste that log to your question in the bbs? wink

Offline

#3 2006-06-28 14:48:11

mucknert
Member
From: Berlin // Germany
Registered: 2006-06-27
Posts: 510

Re: Confused about kernels, ramdisks, modules, etc.

In short: an initial ramdisk makes many crucial modules available at boot-time to even let the machine boot. Having the the xfs-module on a xfs-root doesn't do much good. Having the xfs-module in a initrd at boot time simplifies things greatly wink -- especially for "generic" kernels of distributions that cannot include each and every driver into the kernel.


Todays mistakes are tomorrows catastrophes.

Offline

Board footer

Powered by FluxBB