On Wed, 06 Mar 2013 18:19:09 -0500, Konstantin Kowalski said: > 1.) Currently, I am reading 2 books about Linux kernel: Linux Device > Drivers (3rd edition) and Linux Kernel Development (3rd edition). > > I like both books and I am learning a lot from them. > > I heard that both of this books are outdated, but so far all the > information in this books seems valid and applicable. Is there better > books you would recommend? They're both still mostly applicable. The concepts listed are still valid - certain things need to be locked at certain times, things have lifetimes, and so on. The "outdated" is mostly places where the API has changed slightly - for instance, where api_foo(struct bar *a, struct baz *b) is now api_quux(struct bar *a, struct baz *b, int blat). So you can't cut-n-paste the code and expect it to still work. > 2.) In Linux Device Drivers, it states that module_exit(function) is > discarded if module is built directly into kernel or if kernel is > compiled with option to disallow loadable modules. But what if the > module still has to do something during shutdown? Releasing memory is > unimportant since it does not persist over reboot, but what if the > module has to write something to a disk file, or do some other action? If your module has allocated 128M for a graphics buffer, you'll think releasing memory is important. :) Strictly speaking, a module *should* have already been quiesced and taken care of business before module_exit() is called - there shouldn't be much of anything left to do at that point. (Hint - this is exactly the same question as "why is an empty ->release() function considered a Bad Thing" - it's because release() and similar are supposed to do the clean-up before the module exits) > 3.) What's the deal with different kernel versions? I heard back in the > 2.x days, even kernels were stable and odd versions were experimental, > but with 2.6 it changed. > So with 3.x kernels, are all of them experimental in the beginning and > stable in the end? Also, with 3.x new versions seem to be released more > often than in 2.1-2.5 days. Did the release cycle get smaller or is it > just my imagination? Also, what does rc number mean? The 3.x series is exactly the same policy as 2.6 was - Linus just decided that 2.6.42 was too much and reset the counter, and he's been holding to pretty close to every three months for releases for all that time. And 2.1 got up to 2.1.142 or something insane like that in fewer years than it took 2.6 to get to .42, so it isn't like releases are more frequent these days :) > 4.) Currently, I am running linux-next, and it works great. Am I correct Lucky you. I manage to break at least 2-3 things in linux-next per release cycle. ;) > to assume that linux-next is supposed to have newest, shiniest and most > unstable features? `uname -a` says that I am still running 3.8-next, but > there is already 3.9 out. So which version is more experimental and > least stable? Which one is the newest? Do another pull of the linux-next tree, it will say you're on 3.9-rc1-next now. And even when it said 3.8-next, that was already "3.8 plus all the patches queued for 3.9". Now that Linus's tree is at 3.9-rc1, (closing the merge window for major additions for 3.9) people will be dumping 3.10 material into the linux-next tree. > 5.) How exactly does make/.config work? When I run `make oldconfig`, > does it use the everything from the previous .config and only ask how to > configure new features? Yes, that's what *should* happen. > And when I run `make` does it re-use old object > files if nothing was changed in the specific file, or does it re-compile > everything from scratch? Try it and see. :) Note that sometimes, an apparently innocuous config change can result in the rebuild of lots of files. This is because some commonly used .h file has a #ifdef CONFIG_FOO in it - and when you change FOO, then everybody that includes that .h (even indirectly) ends up rebuilding. But in general, if you touch only 1 or 2 .c files and no widely used .h files, you'll just have to rebuild those .c's if they're modules. If they're kernel builtins, there's another 10 or 12 things that have to happen, but it's still a lot faster than a full rebuild.
Attachment:
pgpHjdRTQp2PO.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
