Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Breaking Into The World Of Kernel Hacking? 202

Posted by Cliff from the learning-the-innards-of-a-penguin dept.
crow_t_robot asks: "In the past couple of months I have become increasingly interested in kernel programming and have finally decided to take the leap and 'get my hands dirty.' I have searched around the web and read a few docs and FAQs on getting started with the kernel but I was wondering what kind of personal experiences those in the Slashdot crowd have had that are so bold as to start goofing with the kernel code. For those that have become competent kernel programmers, how did you 'break in' and what advice would you give beginners?"
This discussion has been archived. No new comments can be posted.

Breaking Into The World Of Kernel Hacking? More

Breaking Into The World Of Kernel Hacking?

Comments Filter:

  • Haven't tried it myself, but... (Score:4, Informative)

    by FatRatBastard ( 7583 ) on Thursday January 17, 2002 @03:35PM (#2857235) Homepage
    ...www.kernelnewbies.org [kernelnewbies.org] is supposed to have a lot for the aspiring kernel hacker.
    • Ok, lets be honest, half way through the question I thought of posting the above, but then I read the whole question, unlike the person above, and decided that would be the totally wrong thing to do.

      Think about it dude, he has spent time reading the FAQ's and such, he wants personal stories, so that is what he should get, sadly though, I don't have that many, well not of the type he wants.

      I wish people would read the Ask /. before posting, mods, please mod the above (and this if you really want to.

      Take care - RL
    • the page and irc channel are great resources.

      I especially liked the 0.01 kernel walkthrough [kernelnewbies.org]
    • Why is that post redundant? It's a rather interesting bit of info actually and it's spot on target.

      Mod tip #666 "Never smoke crack when using them five points"

  • In honor of all the linux newsgroups... (Score:4, Insightful)

    by FortKnox ( 169099 ) on Thursday January 17, 2002 @03:35PM (#2857237) Homepage Journal
    ...RTFM! ;-)

    Seriously, though. Try and find FRIENDLY help. Once you have that, you should be good to go. A lot of kernel hackers are very elitest, and don't take too kindly to newbies, so find yourself a good support group and go from there.

  • That's easy (Score:4, Funny)

    by adlam.bor ( 547789 ) on Thursday January 17, 2002 @03:36PM (#2857247)
    Just start putting together your own VM system. If recent events are any indication, no experience is required.

    (Now taking bets on whether this first hits -1 Troll or +5 Funny).

    • Not exactly right. You do need experience in being convinced that the code you write is superior to all others, despite any indications to the contrary.

  • kernel docs? (Score:5, Informative)

    by Squeezer ( 132342 ) <[awilliam] [at] [mdah.state.ms.us]> on Thursday January 17, 2002 @03:37PM (#2857255) Homepage
    I think the kernel docs would be a good starting point.

    cd /usr/src
    wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2 .4.17.tar.bz2
    tar -jxvf linux-2.4.17.tar.bz2
    cd linux/Documentation
    ls |more

    and start reading all the documentation in there. It would probably make a good starting point.

    Plus you should read Kernel Traffic and get on the Linux Kernel Mailling List.

    • Re:kernel docs? (Score:3, Informative)

      by joib ( 70841 )
      Actually, according to the the README provided with the kernels, /usr/src/linux is _not recommended_, as (depending on distro) you may mess up the header files used by the C library. Another point is that I think /usr/src/linux should be owned by root.src or something like that. So put your tree somewhere else where it doesn't mess up the C library nor your package management system and where you don't need root access. /usr/local, your home directory and with some reservation /opt are good choices (I have my kernel related stuff under /opt/kernel).

  • Linux Device Drivers (Score:5, Informative)

    by AutumnLeaf ( 50333 ) on Thursday January 17, 2002 @03:37PM (#2857258)

    One of the best sources of information is the O'Reilly book on Linux Device Drivers. It contains a lot of good information to get a kernel hacker up and running.

  • Index of Documentation for People Interested... (Score:5, Informative)

    by ekrout ( 139379 ) on Thursday January 17, 2002 @03:37PM (#2857260) Journal
    Index of Documentation for People Interested in Writing and/or Understanding the Linux Kernel >>
    http://jungla.dit.upm.es/~jmseyas/linux/kernel/hac kers-docs.html [dit.upm.es]

    The info was compiled by Juan-Mariano de Goyeneche after folks on the kernel list asked the same questions time & time again.

  • Take it straight from the man... Just Do It (Score:5, Insightful)

    by FauxPasIII ( 75900 ) on Thursday January 17, 2002 @03:38PM (#2857265)
    From Alan Cox's interview posted to slashdot a couple days ago:

    "Ignore everyone who tells you kernel hacking is hard, special or different. It's a large program, and bug fixing or driver tweaking can be a best starting point. It is however not magic, nor written in a secret language that only deep initiates with beards can read.

    Play with it, try things, break it horribly and enjoy yourself. I started on the networking code because it didn't work very well. Everything I knew about TCP/IP I had downloaded the same day I started hacking the net code. My first attempts were not pretty but it was *fun*."

    • Ignore everyone who tells you kernel hacking is hard, special or different. It's a large program, and bug fixing or driver tweaking can be a best starting point. It is however not magic, nor written in a secret language that only deep initiates with beards can read.

      That's great advice for everything in the world, actually. There's nothing so difficult that people can't figure it out, unless you listen to guys in Rome with pointy hats.

    • Re:Take it straight from the man... Just Do It (Score:5, Insightful)

      by Jeremy Erwin ( 2054 ) on Thursday January 17, 2002 @04:28PM (#2857705) Journal
      Hacking the kernel can seem like a daunting task, but nothing focuses the imagination like broken hardware.

      Two cases in point: (the first one isn't a linux story). Someone gave me a joystick for a macintosh. I already possessed a flight simulator for the machine, but much to my chagrin, the joystick didn't have the right drivers. So, I spent the next few weeks writing a device driver (modifying Apple produced code, mostly.)

      Second: I owned a DVD drive with broken firmware-- the capacity wasn't reported correctly, and so oms would stop in the middle of the movie. With the (very) extensive help of "Andrew Ebling" (of kernelhacking.org, I was able to solve my problems.

      Moral of the story: it helps to have good developer documentation, and example code (provided, for the most part, by the kernel source itself) It also helps to have a reason to code.

    • Re:Take it straight from the man... Just Do It (Score:5, Informative)

      by nwanua ( 70972 ) on Thursday January 17, 2002 @04:38PM (#2857801) Journal
      I was glad to see Alan Cox say so, and here's a little personal experience:

      For the past two and a half years, I've been putting some logging code into various parts of the filesystem (ext2, vfs and block device driver.

      This has involved creating new syscalls and user level code to transmit logged data to a remote machine via UDP so we won't adversly affect the FS by logging _and_ writing log data to the same FS. Really trivial stuff in retrospect: the hard part was figuring out where to put what and how to do it without crashing (I worked via ssh and if I hosed something, I was out of luck until I could physically return to campus - which could be as long as a week).

      My favourite book for this has got to be "Linux Kernel Internals": consice, precise with decent examples (IMHO).

      Funny, I worked on module device drivers for a VHDL class _after_ I worked with the kernel directly, so I won't say to you: play with device drivers first to get your feet wet (although, load/unload kernel sure beats the hell out of rebooting). Try doing something simple like changing the messages (printk) within the kernel as a way to gain a small understandinig of what's happening under the hood. And another thing... the source tree I played with was owned by me (so I could cvs, nfs, coda it to my laptop without fear while playing with code (on an OSX PB) on the road :-) You need only drop into root to lilo/reboot

      Cheers.
  • I always carry a small set of lockpicks. Gloves and a mask are a must.

    To protect against modern DNA evidence collection, wrap youself completely in saran wrap except for breathing holes also.

    If you get desperate, cut yourself with something sharp lying around the house and sue the owners. Works every time. Good luck on your new career!

    --KingPrad

    Two fish are in a tank. One says to the other, "I'll drive. You man the guns."

  • There isn't much tricky stuff in terms of programming. (Write good, efficient C code for example)

    1: You need to have a clear goal of what you want to accomplish,

    2: Understand the important concept of Operating Systems,

    3: Know a bit of basic algorithms.

    Then you are good to go.

  • Alan Cox's Columns (Score:5, Informative)

    by pthisis ( 27352 ) on Thursday January 17, 2002 @03:42PM (#2857297) Homepage Journal
    Linux Magazine's Gearheads Only is a great column to read for this, especially the mouse driver and Alan Cox's articles.

    Their web site [linux-mag.com] should have archives.

    Sumner

  • very easy... 10 steps to kernel coding: (Score:5, Interesting)

    by Cheetahfeathers ( 93473 ) on Thursday January 17, 2002 @03:44PM (#2857311)
    1. Learn to code.
    2. Learn to code in C.
    3. Figure out what YOU want to add to the source.
    4. Read the kernel source.
    5. Understand what you read.
    6. Make changes/additions to the source, per step #3.
    7. Test out the changes/additions on your own system.
    8. Make it work for you.
    9. Send in your contribution.
    10. Have it accepted/rejected.

  • Use a kernel debugger (Score:1, Funny)

    by Anonymous Coward
    Connect remotely to a debug build of the OS on a seperate machine than your host machine and step through the code. Set breakpoints at places that look interesting, and just skip over things that don't do much. Watch the registers and keep an eye out for error codes, these will tell you what's going on with the OS.

    Oh wait, you need a kernel debugger...

    Nevermind.

  • start with something simple (Score:1, Funny)

    by Anonymous Coward
    Take a knife and start hacking a cherry kernel. When you become good it at, you can try hacking a peach kernel with an axe, then a mango kernel with a chainsaw, and so on...

  • VMware? (Score:5, Informative)

    by larien ( 5608 ) on Thursday January 17, 2002 @03:45PM (#2857318) Homepage Journal
    It's probably a good idea to run your 'hacked' linux under a virtual system such as VMware [vmware.com] or user mode linux [sourceforge.net]; that way you can do quick reboots without losing your MP3 player, email client, web browser, IDE (VIM+gcc, right?).

    It also means that when you screw things up (if you don't, I'd be surprised; I bet even Alan Cox screws up now and again), you won't lose anything. And don't give me anything about ext3; if you screw up enough in the wrong place, your filesystem is hosed.

    • I agree wholeheartedly, but just to emphasize the point - "now and again" ?! Our most respected kernel hackers screw up all the time! Just try not to submit it if it's b0rked on your system. Kernel 2.4.11 anyone?

  • Kernel Janitors (Score:5, Informative)

    by auto112456 ( 256389 ) on Thursday January 17, 2002 @03:46PM (#2857324)
    Have a look at the Kernel Janitors Project [sourceforge.net] and perhaps KernelNewbies.org [kernelnewbies.org] .

  • Device Drivers (Score:5, Interesting)

    by Eagle7 ( 111475 ) on Thursday January 17, 2002 @03:47PM (#2857330) Homepage
    Buy the O'Reilly book on device drivers mentioned above, and pick a driver you use. Try to understand it, and then tweak it a bit. Since they can be loaded and unloaded, device drivers are a little easier/quicker to play with. And there is a good book on them. ;)

    Working on it during part of an 8 hour work day, in about 1 month I was able to hack tab support into the s390 vm console driver with nothing more than reading code, searching the net, and using that book. And that was probably a little on the slow side. (see here http://www.eagle7.org/ibmlinux.html [eagle7.org]

    And like Alan Cox said in the interview posted to /. a bit ago - Have Fun!

    • Re:Device Drivers (Score:3, Interesting)

      by LordNimon ( 85072 )
      I agree with Eagle7. Start with a very simple driver, one that doesn't actually talk to hardware. Perhaps one that displays some krenel data whenever called.

      From there, you can decide to either move into the kernel itself, or stick with device drivers. If you want to practice on a device driver, stick with a simple ISA device. If you can find the hardware, a driver that displays some text on a Monochrome Display Adapter (MDA) is an easy one.

  • Try this (Score:2, Redundant)

    by DrStrange ( 72008 )
    Read this: http://www.xml.com/ldd/chapter/book/index.html

    Lurk on this for a little while (be prepared for 200+ messages per day):
    http://www.tux.org/lkml/

    Watch for to do lists or bug reports to go flying by on the list and start there. Its probably best if you don't try to implement something from scratch your first time out. Start slow and learn the inner workings first.

  • Writing Kernel Modules (Score:4, Interesting)

    by PlazMatiC ( 11127 ) <slashdot@p[ ].net.nz ['laz' in gap]> on Thursday January 17, 2002 @03:49PM (#2857340) Homepage
    This [linuxjournal.com] Linux Journal article gives a really quick introduction into writing kernel modules.

    It doesn't go into all that much detail, but I found it a good starting point for messing around on my linux machine at home.

    Hth =)

  • Well I think you just dont go into the kernel to be wandering and looking for inspiration. Think about something specific you want to do and get in to it, you'll allways find you have to mess around with several modules or at least get to know 'Where the hell iz thiz thing going??' ;-).

    There are some books at amazon which can helps, I like 'Linux Kernel Internals' by Michael Beck [amazon.com]

    • I've not read 'Linux Kernel Internals', but for a wonderful, detailed, discussion of the Unix architecture I strongly recommend Unix Internals [amazon.com] by Uresh Vahalia. I've recommended this book to everyone who wants a better understanding of what happens "under the covers". Not only is it Chock Full of Good Stuff, it's extremely readable (i.e. you'll have a hard time choosing between it and Maxim for Porcelain Bound Literary Enlightenment)

  • Buy crappy hardware.... (Score:5, Informative)

    by (H)elix1 ( 231155 ) <slashdot.helix@nOSPaM.gmail.com> on Thursday January 17, 2002 @03:53PM (#2857383) Homepage Journal
    Nothing taught me more about kernel modding than spending a few dollars less on the hardware I used on a linux box - and then try to get it to work.

    You become very familiar with code that might be close, get to pour over specs that may or may not help, and find a small comunity of others who saved a buck or two.

    The best part - when it breaks, you get to keep both peices. When if finally works, ahhhh....
    • Exactly! There's no better teacher than adversity. When your computer works flawlessly, you never learn anything.

      But when you've completely hosed your system after getting a new piece of hardware or tinkering an obscure file, you learn a lot about how your system used to work. A recent example of this happening to me what when I tried to install Mandrake over my old installation. I soon learned of the wide world of bootloaders, and why you should never install LILO twice. :P

  • Make your own system call (Score:4, Interesting)

    by BetaJim ( 140649 ) on Thursday January 17, 2002 @03:54PM (#2857389)
    I think about the most easy kernel hack is to create is your own system call. Last year in OS this is what we did.

    The assignment was to add a system call that would return the number of processes created and killed up to that point. The only difficult thing was to grok the system call table. Please look at this option as a good introduction to the kernel.

  • Just Do IT.... (Score:4, Interesting)

    by CDWert ( 450988 ) on Thursday January 17, 2002 @03:56PM (#2857405) Homepage
    Its not like youre going to break anything, real, or permanent, this is all hocus pocus digital alchemy anyhow. If you kernel flies or not, it information, either on what you did right or did wrong. Have fun break some shit. Its no fun it works right all the time anyhow.

    I also highly suggest the IRC channel
    #kernelnewbies
    I went there today for the first time looking for Rik van Riel I had some qustions about the rmap 11b patch and Guess what he was there and told me the 11c is coming today , REAL time info from people that really know their stuff.....

    Kernel hacking can be fun if youre not in a rush IMHO, doing it against a dealine can be ....uncomfortable to say the least.

    Im assuming you know huw to extract the source tree and apply a patch , if not start there. Im also assuming you know C if you dont ....what are you going to hack, or just patch and compile, Look through the tree for stuff you know, see how they do it , see if you think you can do better and try it, start small....... Me, ive never personally done anything that need make it into the tree on a permanent basis. but hey its been 8 years of all kinds of fun.....

    One last point DO IT OFTEN !, Dont let yourself get rusty, Set a goal, a kernel hack a month, or at least a patch and compile a week if youre not cutting code....
  • You're going to screw shit up. Have a crash machine to hack/test the kernel on before you hack your main system.

  • Best advice (Score:1, Informative)

    by jimbis ( 451242 )
    First stop for a total newbie is download an early kernel (try 0.01! [kernel.org]): _much_ less intimidating than the current monster. This should help start you in the right direction. KernelNewbies channel and site are both useful

  • Linux Internals, by Moshe Bar.. (Score:5, Informative)

    by studboy ( 64792 ) on Thursday January 17, 2002 @03:58PM (#2857418) Homepage
    .. is recommended. It's a medium-low level view of the entire kernel, following the source code but making it more readable. If you've taken an Operating Systems or Unix class you should be fine.

    Linux Journal reviewed [linuxjournal.com] it.

    - j

  • Something simple (Score:2, Informative)

    by xer.xes ( 4181 )
    Try to do something simple, like finally adding module parameters to the framebuffer (sorry, personal irritation, but still haven't had the time to do it myself). Then keep enhancing and bug fixing small things, and move on from there to bigger changes... Post your patches on the LKML, and listen to their comments (and 'flame' them if you disagree)...

    That's how I rolled into the business..

    (And if you get me those module parameters, I'll big you the best hug you've ever had :))
  • Kernel Projects for Linux [amazon.com] by Gary Nutt. It walks you through several areas of the Linux kernel. It's a great book. You'll especially learn a lot from discovering all the editing errors in it. :-)
  • ...or another experimental OS. VSTa [vsta.org] in particular needs drivers (and lots of other stuff) so you can easily find something to do, and has many novel design features (being a proper microkernel design -- with almost all work, including traditionally "driver"-style code, done in userspace -- yet faster than Linux) that make it fun to learn about.

    If you're decided to go with Linux, though, just pick something and do it. My first kernel driver was a network driver for a NIC (don't remember the model, it was quite a while ago; Don Becker ended up writing a better driver that was accepted into the official kernel, but it was an interesting experience anyhow). If you have access to any interesting hardware that isn't supported (which may be hard to find on x86), writing drivers or porting to new hardware (not whole new architectures, mind you -- that's a bit much) is a good starting place.
  • Find some small part of the kernel (like a serial port driver or something) and start fooling with it. Disect it and see how it works, maybe fix a bug or two.

    If you're a Windows kernel guy wanting to break into the Linux kernel, thats even easier. Get a job doing a Windows driver for some device, then write a Linux driver for it in your spare time. That's what I did [sourceforge.net].
  • take a look at the linux from scratch side.
    http://www.linuxfromscratch.org

    i think it helps understand how the whole system works together.
    good luck!

  • Kernel trashing :) (Score:5, Interesting)

    by jd ( 1658 ) <imipak AT yahoo DOT com> on Thursday January 17, 2002 @04:22PM (#2857647) Homepage Journal
    I've found that the kernel source code varies in quality between Ultra Brilliant to Infra Crud. (Sadly, a lot of the networking code seems to fall in the latter category.)


    Probably the best place to start is to find some definite itch you want to scratch, and so badly that you won't stop until it's done. For me, that was getting use[ful|less] features into the kernel. As many as I could cram in, without the hard disk exploding. And then fixing all the incompatibilities, as best I could. (Phew!! There are generally a lot!! That's why many of the FOLK patches I produce are unstable.)


    What you do next depends on the "itch":

    • Fixing broken/cruddy code: Generally, it's better to rip it out and start again. Find out what goes in, what comes out, and what is supposed to happen. Software Engineers tend to talk of "black boxes", where one piece of code doesn't need to know anything about other pieces of code. It just needs to know what gets put where. You can use this to test your code outside the kernel. Simply use the kernel headers for the structures, rig up some mock values, and see if your code does what it's supposed to. If it does, then all that's left is cutting & pasting the code into the kernel. Oh, and producing a diff file for the rest of us.
    • Adding new drivers: There should be skeleton drivers in the kernel. Simply fill out one of those. If there aren't, find a driver that's similar to what you want and replace the stuff you don't need, as above.
    • Adding new features: Ignore the rest of the kernel, completely, at the start. Since it's a new feature, rather than an extension of something already there, you're going to be mostly writing new code and working on new structures. The only time the kernel matters is when you want to get data in or out of something thats already there, or when you want to link into some existing capability (such as kernel modules). Then, only pay attention to the API in the headers. The implementation is likely to be replaced three times before the weekend, so spending too much time on it is stupid.

  • Oh well. (Score:1, Redundant)

    by rice_burners_suck ( 243660 )

    The best way to get your hands dirty with any programming project is to get the code, study it for a while, and try to change and improve things. The kernel contains a little bit (or a lot) of everything. Try to fix bugs, improve performance or lower memory usage, if you're skilled at that kind of stuff.

    The most important thing to remember is: Don't be intimidated by the kernel. Think of it as a really big program, because that's what it is. The only difference is that it doesn't get loaded by the operating system... it is the operating system!

  • XINU is golden for learning about internals of OSs (Score:3, Interesting)

    by edrugtrader ( 442064 ) on Thursday January 17, 2002 @04:25PM (#2857671) Homepage
    XINU = XINU is not unix.

    it is a very simple OS with multithreading and a bunch of other stuff.

    the full source is available and only like 8000 lines or something. it steps you through it in the book, and it is EXTREMELY easy to read.

    this was what was used to teach my OS classes in college. you can actually get in and hack the thing away and know what you are changing right from the start.

  • Comment removed (Score:5, Funny)

    by account_deleted ( 4530225 ) on Thursday January 17, 2002 @04:26PM (#2857675)
    Comment removed based on user account deletion
    • It's called XP
    • - "Ha! Just Kidding!" memory manager: when an app requests a memory allocation, periodically claim that it has failed for no reason at all. That'll keep 'em laughing forever!


      This is built in in debug-mode in the Symbian [symbian.com] operating system - if you want. It helps in checking where you've written sloppy code that doesn't handle out-of-memory correctly (about 100% of all code written for desktop-systems actually, but since the Symbian platform is targeting smartphones and communicators it's a lot more important there)

  • BSD (Score:2, Informative)

    by grendel's mom ( 550034 )
    Give the FreeBSD or OpenBSD kernel a try. I jumped right in with these. They have tons of documentation, are friendly and relatively forgiving (if you can call a kernel 'forgiving'). My first attempts involved a simple "undelete" feature. This is a nice starting point as it requires not only knowledge of the kernel, but of the file system as well. A great learning tool. But BEWARE: you first attempts shouldn't be on a machine with your PhD thesis or 36 GB mp3 collection. Set up a new, raw machine and start hacking away. Have fun!

  • Kernelnewbies.org (Score:2, Redundant)

    by HairyBN ( 252481 )
    Here's a good place to start, the web page [kernelnewbies.org] and the irc channel on irc.openprojects.org #kernelnewbies.

    Happy Hacking!

  • Starter projects... (Score:3, Interesting)

    by stripes ( 3681 ) on Thursday January 17, 2002 @04:29PM (#2857717) Homepage Journal

    A good starter project is a device driver for something simple. Even easier is if you find a device Net/Free/OpenBSD supports and Linux doesn't, port the driver, that way there is somewhat less code to write.

    That could be harder for you then me since Linux has so many drivers now (I started with 386BSD 0.0, so there were maybe 15 supported devices...my friend and I ported the MACH SoundBlaster driver). If all else fails, write a driver for something that already has a driver.

    After that you can wonder off into the kernel proper and do some "real" stuff. I did IP traffic shaping, but someone seems to have done that to Linux already...

    • Maybe something like grab a serial cable, hook up one end to the comp and the other end to a set of LEDs and then write a device driver that lights up the LEDs based on whether the webserver is server or the mail server is getting mail or something. Maybe collaborate with an EE at your school or something.

      In any case, I would think it'd be easier the other way, that Linux has more drivers than BSD. Maybe he should try your suggestion in the opposite direction?
      • Maybe something like grab a serial cable, hook up one end to the comp and the other end to a set of LEDs and then write a device driver that lights up the LEDs based on whether the webserver is server or the mail server is getting mail or something.

        Simpler with a parallel port (and a bunch of LEDs, like a volume meter)...still there is a problem with debugging both a new driver and new hardware at the same time....

        In any case, I would think it'd be easier the other way, that Linux has more drivers than BSD. Maybe he should try your suggestion in the opposite direction?

        Well, if he wants to be a Linux kernel hacker starting with the BSD kernel isn't going to be the most helpful thing in the world...of corse BSD could use more kernel hackers, and it might be easier to make it "big time" in the less competitave BSD world (except some of the BSD hackers have been doing this for a very long time and are very good at it...like since the early 80s...which is why they can do so much with so many fewer people...)

        If he really wants to be a Linux kernel hacker, he'll be better off taking a driver from *BSD, even if it is for a device Linux already has, and porting it. He will learn more about Linux that way then the other way around (I use BSD machines more frequently, so it would benifit me more for him to become a BSD kernel hacker, but...)

  • Linux Core Kernel Commentary (Score:3, Insightful)

    by ScottMaxwell ( 108831 ) on Thursday January 17, 2002 @04:31PM (#2857736) Homepage
    I'd recommend Linux Core Kernel Commentary [barnesandnoble.com], whose first edition was favorably reviewed [slashdot.org] right here on Slashdot. It's unlike other kernel books in that it examines much of the core of the Linux kernel code line by line; it's a good way to pick up a lot of the code's idioms and to learn to think like a kernel programmer, but this approach necessarily narrows its coverage. Depending on your specific interests, this might be the perfect book for you, or it might serve well as a companion volume to a book with broader/different focus.

    The publisher has a sample chapter [coriolis.com] online (though their HTML looks weird to me; I hope it looks better in your browser). Also, you can read a little more about the book, find links to online reviews, get errata listings, and so on, at its support site [scottmaxwell.org].

    Oh, and I, er, happen to know the author. :-)

  • The Academic Answer (Score:2, Informative)

    by DCowern ( 182668 )

    This might not be the sort of answer you're looking for because it's expensive and will take a few months (at least) but if you haven't already, look at taking a formal course in operating systems. At my university it's a 300 level course and has some heavy pre-reqs but I've seen it offered at other universities with only the requirement of prior programming experience.

    The course I took in opiples that make an operating system "go" -- scheduling, physical and virtual memory management, we touched on sockets and pipes (it was a *nix-centric course but we discussed other operating systems including Windows, as well).

    If you dont want to spend the time or money on a formal course, I'd at least reccomend the dinosaur book. While lacking in code examples (it doesn't try to show you how to write a *nix-like OS in C, it tries to explain concepts that can be applied to any platform, any language, etc.), it is extremely thorough and makes hard concepts easier to learn. [amazon.com]

    While I haven't actually read it (yet), I hear Tanenbaum's Modern Operating Systems [amazon.com] is also excellent.

  • I was forced to do it (Score:3, Interesting)

    by BurpingWeezer ( 199436 ) on Thursday January 17, 2002 @04:37PM (#2857788)
    Well, I wasn't forced to do it, but we had a class on it at my school, the University of Alberta. The class was officially called system and network management but was unofficially called "kernel hacking". Why? Well, the goal of the class was to put to practical use all of the OS concepts we had learned in previous years. Kernel hacking is perfect for that.


    We were given a problem to solve: build a kernel patch to any version of the linux kernel that allowed a third party who is writing is driver to have the driver interact with a software emulator instead of real hardware. The end goal was to enable people to write drivers based only on the hardware specs and an emulator. The emulator would instruct the kernel to route certain hardware calls to it. After the driver was written the real hardware could be dropped in place and the driver would not have to be re-written, it could be used out of the box. Essentially it was hardware abstraction without knowing what hardware to abstract before hand.


    Personally, if you are just looking at getting into it just find yourself a problem and solve it. It doesn't matter what problem it is, any problem, useful to the world or not. Remember that the end result of this step is to learn, not solve 2.4 VM problems, or to build a better SMP design. (That's the next step!)

  • Testing... (Score:3, Informative)

    by Refried Beans ( 70083 ) on Thursday January 17, 2002 @04:38PM (#2857800) Homepage
    If you like to see how things work, the best way is usually to write some code that tries it out. With a little extra work, you can create a small test case. Then submit the test program to the Linux Test Project.

    Linux desperately needs more serious testers.

    LTP - http://ltp.sf.net/
  • because of two reasons:
    a)The elitist attitude of some, who will tell you to go RTFM. And unless you are willing to write code for a really old kernel, you won't find much documentation. And even so, the little free documentation you will find, is not that helpful for newbie kernel hackers (and I don't mean to piss on the efforts of those who have written docs, but they're complex to digest for real newbies).

    b)The recipe-minded newbie. Let's face it, you won't find a connect-a-b-and-c-shake-bake-and-wham!-You-have-a- module guide or howto. You have to be armed with good C knowledge, and some idea of how a computer _really_ works (understand interrupts? memory addresses?). If you want to write for a current kernel (say, 2.4.17), you _will_ have to look at the source code, and actually try to understand what is happening (told you you'd need to know C). You will also need to know, or at least have some idea of how the peripheral you're writing code for (say, if you're writing a driver module) works.

    My experience: I was an absolute newbie to kernel programming, so I started reading the code for the tty driver on kernel 2.4.0, which seems to me is one of the simpler parts. After a lot of reading, I wrote my own module (it was just for fun, so don't think it was anything useful...) as a simple device you could write data to, then read it back. Try it on a machine you don't mind screwing up, though, because you will have tons of oopses and kernel panics.

  • x86 Emulators, etc. (Score:2, Informative)

    by alexalexis ( 31082 )
    If you don't have a spare PC laying around, VMWare [vmware.com] is a pretty spectacular way to get your hands dirty without having to worry about completely hosing your development machine on accident. The only thing you really can't do with VMWare is hardware level drivers, for obvious reasons.

    If you really want to get gritty on the emulation level, I highly recommend Bochs [sourceforge.net]. It's a fully functional x86 emulator, and since it's open source, it comes with some nifty options, and the source code is on hand if you really need to get tricky.

    I think the key to working efficiently with an x86 emulator/virtualizer is having a significant amount of RAM, and a RAM disk to mount your virtual drives on. Since RAM is so cheap these days, there's no excuse not to have at least a gig of it in a development box. It makes rebooting the virtual machine (which happens a lot) a bearable process.

    If you need to work with hardware, you can build yourself a test platform for around $300 now, including a cheap monitor - unless you need exotic hardware.

    My experience kernel hacking is in on the VFS level, inserting and modifying a few core routines to report through a /proc interface ... and it was pretty easy to get into. I started with a basic understanding of how things work (inodes, etc.), and it came pretty easily. If you're going to be working on file systems, make periodic copies (backups) of your virtual drive image (if you're using VMWare/Bochs) ... it's a life saver for the first few weeks. :)

    The kernel is complex, but so is any major piece of software. Thankfully, lots of bits in the kernel are well engineered and compartmentalized, so chances are you won't have to worry about screwing up the TCP stack if you're in the midst of inode.c ...

    have fun!

  • Do as I did (Score:4, Insightful)

    by ajv ( 4061 ) on Thursday January 17, 2002 @05:38PM (#2858327) Homepage
    Get down and dirty with a kernel project. I chose Reiserfs on alpha.

    This taught me a lot about lkml politics, which is probably the first skill (and some larrikins would say, the only skill you need) you must master to be a successful long term kernel hacker. First lkml hint: don't slag off anyone. Don't piss off a few people in the know until you get to know them, and then...

    Then, don't talk - do. Respect is directly based upon your skills with patches, and their acceptance rate.

    Patch submission. Follow the standard guidelines (found elsewhere), but know now that Linus sucks at code control. The mainline kernel development process is slow, prone to serious lossage, allows regression, and is irreparably harmed by Linus' refusal to adopt modern code control practices. So when you submit a patch, don't worry if it's not accepted. Every time the kernel is revved, re-do your patch and re-submit. It'll eventually be accepted, particularly if it helps the kernel boot. For example, it took nearly a month of my submitting a two line patch to allow the alpha to boot before it was accepted into mainline 2.4.0pre development. That's why I ditched Linux for a while - dickheads in charge. All the *BSDs have better kernel development practices, and their bleeding edge kernels are far more stable than any stable Linux kernel. However, for various reasons, I get attracted back to Linux on a regular basis, like a fly to a pus-filled boil.

    Anyway, the things that need desperate attention are:

    the kernel janitor project (clean out the cruft!)
    the linux kernel testing project

    These are far more important than any single feature you might want to add, and in particular the kernel janitor project will help you get familiarized with the kernel the quickest.

    http://sourceforge.net/projects/ltp/
    http://sourceforge.net/projects/kernel-janitor/

  • Major stumbling block: debugging (Score:3, Informative)

    by drix ( 4602 ) on Thursday January 17, 2002 @05:44PM (#2858377) Homepage
    About two years ago I was in the same place you are. I wanted sound on my notebook, and, while a driver did exist for my chipset, it was extremely buggy with my particular setup and resulted in an instantaneous hard freeze. It didn't appear to be under any further development, and, to make matters worse, the specs for the chip hadn't been released and the author, having "divined" them out of thin air, did not wish to be contacted. So I undertook to debug it myself.

    Let me say that, at least for me, this was not like debugging any of the userspace programs that I had done before. If you're like me, when your program crashes, you first up gdb, load the core, and backtrace/step from there. First of all, there's no core dump. In this case I didn't even have the luxury of an oops readout; as I would find out later this particular bug was locking the computer even before the kernel could flush its output buffers and print to the screen.

    So I had to start meticulously reconstructing the function call stack using printk(). It took me awhile before I figured out why none of these were getting printed (for the reason I just mentioned.) So that didn't work either.

    I searched high and low but never did find a way to debug the kernel that was as easy as using gdb to debug a userspace program, and that's not saying much. No stepping, no backtraces, nada. The "bug" in my particular driver consisted of a single offending line which wrote an 8-bit register and was not to spec. I would have never ferreted it out if I hadn't "stumbled" across the NDA'd specs myself.

    Anyways, moral of the story: kernel debugging sucks for really hard bugs. If anyone knows of better tools to use kindly inform me of them.

  • HOWTO at http://www.kernelhacking.org (Score:3, Informative)

    by kernelhacker32 ( 551835 ) on Thursday January 17, 2002 @05:55PM (#2858481)
    You can find a half baked kernelhacking-HOWTO at http://www.kernelhacking.org [kernelhacking.org]

  • Start with the MBR... (Score:2, Informative)

    by jquirke ( 473496 )
    Start reading the MBR, then follow the chain of execution until you are deep into the kernel...

    That's how I started on the FreeBSD kernel and the Linux kernel.

    Sure at the first there's some dependencies - and you are sent on a journey through about 20 H files just to find one #define ition, and to know A you need to know B, which requires C, but it worked for me.

    --jq
  • Getting started with embedded systems has never been easier. Go buy a Sega Dreamcast for $50 (Try to get one with a manufacture date of November 2000 or earlier). Then, go read this article [linuxdevices.com].

    You'll have linux up and running on the thing in no time, and you'll be able to play around with writing device drivers and fixing kernel scheduler bugs and stuff. All on the SH4 processor, which is much simpler than the x86 you're probably using.

    Cryptnotic

  • Before you dive in, read this!!!! (Score:5, Funny)

    by 2Bits ( 167227 ) on Thursday January 17, 2002 @06:45PM (#2858856)
    Oh so, you want to hack kernel? Well, let me tell ya, before you get in this, you need to do the following prelim works:

    • Divorce if you are married, unless your other half also wants to hack kernel. Even that, make sure you two don't hack the same module.
    • Say goodbye to your bf/gf, unless your significant other also wants to hack kernel. Even that, make sure you two don't hack the same module.
    • Get rid of redundant furnitures. You'll have a lot more computers, so you need space.
    • Get a good air conditioner. Oh yeah, all those computers you have, it's going to be hot.
    • Get a good and large freezer. Read next items to see why.
    • Stack up a lot of beer, coke, moutain dew.
    • Get a good coffee maker, with a big pot, preferably with vacuum insulation.
    • Stack up a lot of coffee
    • Stack up a lot of frozen pizzas and frozen food.
    • Get rid of your lamps. You don't need that. You'll glow anyway.
    • Get rid of all your light color clothes. Get some black clothes. Any kernel hacker worth two cans of beer will wear black clothes.
    • Get rid of your razors. Any kernel hacker worth two cans of beer will have beard. Linus is an exception, his skin is too thick, so it doesn't even grow.
    • Save money on soap and detergent. Any kernel hacker worth two cans of beer is smelly.


    Ok, now you can go back to read all these good advices that other /.ers gave.

  • Dual keyboards with seperate keyboard mappings! (Score:5, Interesting)

    by karlm ( 158591 ) on Thursday January 17, 2002 @06:47PM (#2858879) Homepage
    I did my first real kernel programming (besides a little "hello, woeld!! This is the kernel speaking" module). Last week. My keyboard died a few months ago and I didn't have time to mess with it, so I went out and baught and IBM USB/PS2 keyboard (Rapid Acess Pro) and hooked it upto my machine as a PS/2 keyboard.

    When I had time, I went and fixed the old keyboard, and rearranged the keys as a Devorak keyboard while I was at it. Unfortunately, the USB-PS/2 dongle that came with my IBM keyboard doesn't work with my Dell PS2 keyboard. However, I currently have the IBM keyboard hooked up to my USB port and my old Dell keyboard (with rearranged keys) as my PS/2 keyboard.
    Luckily, keybdev.c (both the one in drivers/input and the one in drivers/usb) is astonishingly short. There's all of about 5 functions in there and most of the complexity is hidden in other modules.
    The USB keyboard driver interfaces the PS/2 subsystem IIRC (don't know where I read this, maybe the hid.c documentation on linux-usb [usb-linux.org]) so you can't have seperate keyboard mappings, unless you munge the keycodes inside the USBdriver. As long as you don't lock up your USB keyboard driver or have a buffer overun, you should always be able to restart.
    I have LILO (GRUB, actually) setup to boot me into either a 2.2.20 kernel or a 2.4.17 kernel. That way, I can ensure that my hacked module won't be loaded by hotplug if I screw it up.

    The Steps I took
    Downloads I downloaded the 2.4.17 source code and used apt-get to install kernel-package (makes Debian kernel packages, so your nightly apt-get upgrades won't destroy your work).
    Renaming I went into /usr/src/linux (after untarring the 2.4.17 source) and changed the line near the to from "EXTRAVERSION = " to "EXTRAVERSION = -maxmodular" this changes the name of the kernel from vmlinuz-2.4.17 to vmlinuz-2.4.17-maxmodular and makesa seperate directory in /lib/modules for your hacked modules. (I called it maxmodular because I even made the "misc binary support", "a.out binary support" and "floppy drive support" as modules.) Potential Gottcha: IDE support is no enabled by default, and comes after the IDE-parport questions in the config menu, so I must have recompiled 10 times trying to figure out why it couldn't mount the root partition.
    Snooping arroundI poked around the drivers/usb/ kernel source and documentation some to try and figure out what needed to be hacked. I incorreclty identified drivers/usb/keybdev.c and after none of my printk's worked, I tried drivers/input/keybdev.c (this does not affect the PS/2 keyboard).
    Printk() is your friend. Add printk()s (printk() works just like printf(). Make sure to do your kernel module insertion from a non-X virtual terminal to minimize the time it takes prints to get to you in the case of an impending crash.) to the beginning of every function in the driver, letting you know that it's being called (and optionally the arguments). Then recompile and load your module. This gives you a feel for how the driver works and confirms that you have the right driver.
    Trim prink()s to only print out the information you need. In my case, I got rid of the printks from everything but the keyboard event handling function and the emulate_raw function kalled by the event handler. I printed out every keycode that was pressed (but not it's release) so that I could write down the keycode for each key I needed to remap. (And some of the neat colorful buttons IBM added above the funtion keys. I later used these to turn on and off the devorak remapping and turn on and off the printks in my module.

    After that, what you do is pretty specific to your module. For keyboards, they send a 16-number, called a scancode that is one of the arguments to the keyboard event hadler function. All of the normal keys have scancodes less than 256, so I just made an unsigned char[256] usb_key_remap_table and did something like
    if (code < 256 && code >= 0) {code = usb_key_remap_table[code];}
    The more astute amoung you will remeber that I'm only remapping the USB keyboard, which is my good keyboard and therefore unmodified. Oh well, I figure having the incorrect letters written on the keys discourages me from looking down.

    Anyway, the USB subsystem seems very readable for the higher level drvers and USB keeps getting more and more devices, so I'd recomed starting with a USB subsystem... too bad RadioShack is out of USB cue:cats :-D

  • I actually wrote something up that was recently posted online at the linux journal site: http://www.linuxjournal.com/article.php?sid=4715 [linuxjournal.com] Since I wrote it over a year ago, some of the links are a bit out of date, but the general principles are still good.
  • For those who don't remember their history, MINIX was a complete UNIX kernel (and environment) developed by Andrew S. Tanenbaum SPECIFICALLY to teach UNIX kernel internals. It was documented in his book Operating Systems: Design and Implementation, which includes the ENTIRE source code listing for the kernel.

    MINUX was never designed as a real-world system, although it did inspire at least one person, namely Linus Torvalds, to write one...

    -p.

  • Be adventurous (Score:2, Insightful)

    by Anonymous Coward

    I started programming in the linux kernel many years ago. I think the thing that helped me the most is that at first I just stuck to one thing. I didn't try to get it all at once. Kernels are very large, and there are a few tricks to kernel programming that aren't as intuitive as applications programming. After playing around in the TCP/IP stack I just branched out a bit. After a while whenever I encountered some new routines or structure, I tried to read every bit of code involved with it.

    Some years later I decided to switch to *BSD. I have found their source to be much cleaner and their debugging tools are far more useful for me. After I felt comfortable enough with BSD I started contributing code back. At first small things, and then gradually larger projects. Now I do custom FreeBSD kernel code for a living. I do everything from new file systems to device drivers and custom TCP/IP code. I enjoy it much more than user space programming.. I always joke that I did it all to get away from getopt(3) though. :-)

    There are a variety of books you can read on the topic. Don't restrict yourself to linux books, please. Learn that there is more than one way to solve a problem. I'll list some of my favorite kernel books here:

    "The Design and Implementation of the 4.4BSD Operating System"
    "UNIX Internals: New Frontiers"
    "Solaris Internals"
    "UNIX Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers"

    After you get a rough idea of how the kernel works, the only way to really learn it is to read code and research papers.

    Good luck. :-)
  • Were you thinking of doing some work on Darwin [darwinfo.org]? That would be a much better choice than Linux, of course. Darwin is based on a free-as-in-speech license [apple.com], unlike Linux. Linux is licensed under the GPL, which places all kinds of restrictions on your freedom to use the code; for instance, you can only link it to other GPL'd code. Also, Darwin is a microkernel design, so unlike Linux, it actually has a future on the desktop -- you can actually install a new device driver without recompiling the kernel.
  • The "Gearheads Only" section of Linux Magazine have a few interesting article :

    http://www.linux-mag.com/depts/gear.html

Slashdot Top Deals

A fail-safe circuit will destroy others. -- Klipstein

Close