LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 11-28-2007, 03:00 AM   #16
evilDagmar
Member
 
Registered: Mar 2005
Location: Right behind you.
Distribution: NBG, then randomed.
Posts: 480

Rep: Reputation: 31

Quote:
Originally Posted by Alien_Hominid View Post
Thanks for a great explanation. Several questions:

1) Why make clean is required when you change only the core of the kernel?
Let's take the six permutations of changes and walk through what can go wrong with them.

a) Code was in the core kernel, but is being turned off entirely - stale objects could still include hooks to whatever you just removed.
b) Code was in the core kernel, but is being made into a module - stale objects could still include symbols for code which will now be in a module. Load a module with symbols that are already present in the kernel and *bang* it'll kick it right back out.
c) Code was a module, but is being disabled entirely - no problem here. make modules_install wipes the target directory before installing everything, so the now no-longer-compiled module quietly goes away and the kernel was unaffected by the change.
d) Code was a module, but is being moved into the kernel - Stale objects in the kernel might result in things hitting a dead end when they should continue execution through the code now added to the kernel.
e) Code was never enabled before, but is to be built as a module - same effect as C, actually.
f) Code was never enabled before, but is to be built into the kernel - same effect as D.

I was originally somewhat of the impression that cases a, b, and d would result in the Makefiles figuring out that some objects may need rebuilding, but apparently there are ways for code to be more clever than Makefiles can easily figure out. (To spot everything, Makefiles would have to test not only the object they're worrying about, but every other object that could affect it, and every other object that could affect that, and so on.) From reading the LKML I finally just gave up worrying about it, since the "FTW" scenario is to build as much as possible as modules anyway, the times when someone might need to actually clear things out should be few and far between (maybe twice a year for me, maybe). Building entirely monolithic kernels is just as dead as the last pope.

Quote:
Originally Posted by Alien_Hominid View Post
2) What's the difference between those two?
...as far as I know, vmlinux isn't compressed, and bzImage is (with bzip2).
 
Old 11-28-2007, 09:32 AM   #17
Alien_Hominid
Senior Member
 
Registered: Oct 2005
Location: Lithuania
Distribution: Hybrid
Posts: 2,247

Rep: Reputation: 53
Maybe I didn't understand what a stale object actually is, but anyway isn't a module by definition a non-dependant part of software, which can be loaded anytime you want, without taking care of what configuration kernel really loads it? As I have understood till now only kernel can call module functions and not vice versa. It (module) shouldn't have hooks back to the calling program if it isn't programmed with this purpose specifically like to intercept some syscalls, which is a different case.

Code:
file /boot/vmlinuz
/boot/vmlinuz: x86 boot sector

EDIT:

And why f is d?

In addition, never checked make modules source, but doesn't it clean already made modules before making new ones? And I've always try to run solid kernel except iptables which do not work if they're built into the core. What's wrong with solid ones?

Last edited by Alien_Hominid; 11-28-2007 at 09:45 AM.
 
Old 11-28-2007, 04:05 PM   #18
evilDagmar
Member
 
Registered: Mar 2005
Location: Right behind you.
Distribution: NBG, then randomed.
Posts: 480

Rep: Reputation: 31
Quote:
Originally Posted by Alien_Hominid View Post
Maybe I didn't understand what a stale object actually is, but anyway isn't a module by definition a non-dependant part of software, which can be loaded anytime you want, without taking care of what configuration kernel really loads it?
stale object: (mostly) any *.o (object) file that was previously compiled using directives which may very well no longer be in place.

Sure, you can load a module without worrying about the configuration of the kernel, provided they don't have features that overlap each other. You can see what happens when this is going on by booting the huge kernel, and then trying to load the USB mass storage modules (which has been reported on this forum from people several times now). Just like when you include two differing versions of the sort-of same library into one binary (ever seen what happens when you link libgtk+-1.so and libgtk+-2.so into one binary at the same time?) you can have a equivalent of a symbol collision in the kernel quite easily.

The thing that I suspect people overlook is that there is not a 1:1 ratio of config items to chunks of kernel code. There's numerous things which pull in more than one piece of code, and some which pull in bits of code depending on whether or not they're already being pulled up.

Let's say that A pulls in B, and that C also pulls in B if nothing else has done so. Now we'll say that A has in fact pulled B into the kernel, and then C gets compiled later with a different config that leads it to believe it needs to pull in B still. C+B modprobing into A+B equals BLOOEY!. NOW at least, the configurator seems to prevent really dim things going awry there, but in 2.4.x kernels I don't think things were checked as carefully (or were probably done in an entirely different way) because numerous times with 2.4 I managed to set up configurations involving me trying to be selective about which USB modules/drivers I built in, just to get a kernel that wouldn't even compile without dying halfway through because of some module I'd skipped enabling which resulted in (apparently) unexpected things being missing for the parts I did compile.

Quote:
Originally Posted by Alien_Hominid View Post
As I have understood till now only kernel can call module functions and not vice versa. It (module) shouldn't have hooks back to the calling program if it isn't programmed with this purpose specifically like to intercept some syscalls, which is a different case.

Code:
file /boot/vmlinuz
/boot/vmlinuz: x86 boot sector

EDIT:

And why f is d?
Think of all the blocks of code like literal blocks with wires sticking out of them. Compiling them solders the wires together that link all the pieces, and snips off the leftovers that don't go anywhere. Adding a new block after the kernel is finished could leave you with nothing to connect the wires to, or wires connected to more than one place at a time that shouldn't be (figuratively speaking).

Quote:
Originally Posted by Alien_Hominid View Post
In addition, never checked make modules source, but doesn't it clean already made modules before making new ones? And I've always try to run solid kernel except iptables which do not work if they're built into the core. What's wrong with solid ones?
It doesn't wipe anything. If you go into menuconfig and add one new module to be built, when you run `make modules` it'll build that module alone and be done with it.

As to entirely monolithic kernels, there's really no point anymore. You just get a big kernel that might be too large to load with no benefits. It was proven wrong ages ago that you couldn't force the kernel to load a module anyway (rootkit modules, anyone?). You can *add* or *blacklist/remove* modules later if you need to change something, but you have to build a whole new kernel if you're going monolithic. (Which means that even though they're lottery odds, you invite the chance that some obscure compiler bug could manifest throughout the entire kernel instead of just the new module.) There's no meaningful level of overhead involved in using modules, and now with kmod and udev doing what they're supposed to, they spring up for pretty much everything you have without prompting (so less chance of the intern loading the wrong driver module). If I were looking to make a super-super-teeny-tiny kernel, or one for an appliance whose hardware facilities would never ever possibly change (like a specific model of PDA or router), I'd probably go monolithic, but nowadays even my PDA has 8Mb of RAM in it, which is more than the amount of RAM the first machine I assigned an IP address to and put online had. I'm not going to get quibbly over anything less than 100K without good reason.

Last edited by evilDagmar; 11-28-2007 at 04:07 PM.
 
Old 11-28-2007, 05:15 PM   #19
Alien_Hominid
Senior Member
 
Registered: Oct 2005
Location: Lithuania
Distribution: Hybrid
Posts: 2,247

Rep: Reputation: 53
I've read your response. Thank you. Will read it again tomorrow with clear head.

The problem I see with building modularized kernel is that you actually don't know whether this module is used or not and why is it required at all (because udev and other tools do all the work for you (I don't use these, neither udev nor hotplug)). You're (not specifically you, but people) building hundreds of modules without really considering if they're useful or not. Because I specifically build kernel for my box and it doesn't change a lot (in the last four years this box had only mb changed, cause I've burnt USB controllers), I consider monolithic kernel a wise choice. Yeah, there isn't noticeable speed or memory gain, but still...

BTW, why such tools as insmod and rmmod exist if modularized kernel is so good?
 
Old 01-01-2008, 07:23 AM   #20
Alien_Hominid
Senior Member
 
Registered: Oct 2005
Location: Lithuania
Distribution: Hybrid
Posts: 2,247

Rep: Reputation: 53
Finally found time to reread.

AFAIU (understand), f can't be d, just because f part was not referenced from any other parts of the kernel, adding it to the kernel shouldn't make wrong (stale) references to its previous location.

It's strange that bzImage is called x86 boot sector and not simply bz2 archive.

Quote:
Let's say that A pulls in B, and that C also pulls in B if nothing else has done so. Now we'll say that A has in fact pulled B into the kernel, and then C gets compiled later with a different config that leads it to believe it needs to pull in B still. C+B modprobing into A+B equals BLOOEY!
This applies only to modules and not to solid kernel, doesn't it? BTW, we can control which modules are modprobed with what options, so I can't see a problem in C modprobing B again (I'm not even sure if kernel lets you to modprobe same module again. Even if it is possible, you can always remove additional B line).
 
  


Reply

Tags
compile, kernel, options


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How do you mount a USB thumbdrive in RH9? dsschanze Linux - Hardware 6 12-29-2005 09:42 PM
Memorex USB Thumbdrive will not mount on RH9 - USB conflict Tsatellite81 Linux - Hardware 1 02-24-2005 01:01 PM
usb thumbdrive after kernel compile : slackware youknowwho Linux - Hardware 0 01-10-2005 10:32 PM
usb thumbdrive. can't mount? not listed?! FLOODS Linux - Hardware 12 08-06-2004 12:39 AM
how to mount a sony usb thumbdrive? lohdavid Mandriva 1 08-28-2003 10:09 PM


All times are GMT -5. The time now is 09:36 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration