Several unrelated beginner questions.

[Valdis.Kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130306/0c5da86e/attachment.bin