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:
pgpsPHNmO7ZAI.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
