Re: New text

["Valdis Klētnieks" <valdis.kletnieks@vt.edu>]

[-- Attachment #1.1: Type: text/plain, Size: 2816 bytes --]

On Wed, 19 Feb 2020 10:54:10 -0500, Ruben Safir said:
> is there currently a rfecommended text to learn kernel development from?

The first thing to remember is that the kernel has no obligation to be easy for
new programmers. It's more like a Formula 1 race car than a Ford Escort -
there's an expectation that you *really* know what you're doing when you put
your hands on the steering wheel.

As a result, the authoritative source on that is, of course:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Seriously - the kernel is a work in progress, and it's in motion all the time.
There's no way to write a text that's up to date - by the time you finish, the
source tree has moved by 3 or 4 million lines.

Currently, the best is probably Linux Device Drivers, Third Edition (just
google for LDD3 and you'll get a pointer to the PDF).

However - keep in mind that it discusses *concepts* like locking and variable
lifetimes and so on.  It's now somewhere over 15 million lines out of date, and
it's expected that if you can't figure out for yourself what concepts mean, or
what the *current* API is, then you probably shouldn't be writing large chunks
of kernel code that requires undertanding the current APIs.

Note that many bugs are fixable without knowing all that - it's often a
"somebody added A and B, when it should have been A - B" or a stupid null
pointer mistake, or similar.  And drivers/staging is just *full* of stuff that
is in drastic need of help.

Protip: if you've been handed a device dqriver for a 4.7 kernel, and been told to make
it work under a 5.5 kernel, and you have *no* idea how to fix all the compile errors,
the way to proceed is usually:

0) Kernel API changes are *supposed* to break a compile - if you used to pass
an integer as the third parameter, and now it's a pointer to a structure, the
build will break.  Anybody who makes a kernel API change where the third
parameter used to be an integer that meant one thing, and changes it to an
integer that means something else, so it will compile but not work correctly,
will probably get smacked around with a large trout or something. (A common
work around for this is changing a function from (struct *A, struct *B, oldint)
to (struct A*, newint, struct *B) so the compiler will whine).

1) Start wading through the git log until you find the commit that changed the
API. In either that commit, or a commit in the same series, whoever changed the
API also changed all the in-tree users of the API.

2) Look at that commit, and see what got changed in all the in-tree users.

3) Do the same thing to your out-of-tree code.

And here you thought it was difficult, :)

(Of course, if you're trying to get a 2.6.12 driver working on 5.6... you may decide
that it's time to start drinking heavily :)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies