Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Apple Businesses

OS X Kernel Overview 28

Don Negro writes: "Found this on Apple's Developer site. A solid overview of the OS X kernel - what bits are Mach, what bits are BSD - and a good level a detail. This is the first installment. As they say in the introduction 'Only you can prevent kernel panics.'"
This discussion has been archived. No new comments can be posted.

OS X Kernel Overview

Comments Filter:
  • I wasn't any of the mentioned in the "who should read this book" section... guess I'll have to wait till some educated /. reader para phrases it...
  • by Sentry21 ( 8183 ) on Monday January 14, 2002 @10:11PM (#2839853) Journal
    I opened the link and read through the introductions, with the intent of reading. I'm a middling-to-pathetic C/C++ programmer, and I figured it might be interesting to join into the kernelnewbies project - then this came out.

    Now, I'm scared. Honestly, after reading through that introduction, I'm scared to touch kernel code. Hell, I'm scared to look at it.

    I think Apple did a great job with this document. They don't want anyone writing code unless they know EXACTLY what they're doing (the code, they say, has to be well nigh perfect), so they put in as much intimidation as they can manage without being overly conspicuous.

    The newbies will be scared, the people with no confidence (like myself; I don't remember ever compiling warningless code on the first go; if I'm writing something complex, I'll miss a }, if I'm writing Hello World I'll forget to #include) will be scared. The only people who will even think about trying their hand at kernel programming are Gods and fools.

    Good job Apple, you really know how to screw with heads. ;>

    --Dan
    • by Arandir ( 19206 ) on Tuesday January 15, 2002 @02:24AM (#2840633) Homepage Journal
      Now, I'm scared. Honestly, after reading through that introduction, I'm scared to touch kernel code. Hell, I'm scared to look at it.

      That's kernel code for you :-)

      You can be the best programmer in the world, know assembly/C/C++ inside and out, and all that jazz, but when you hit kernel code it's like a different reality.
      • From Alan Cox, in the kerneltrap interview running on the front page of slashdot right now:

        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*.


        Sumner
        • My point was not so much that kernel code is different from systems or application code, but that the *domain* is so different.

          An analogy can be made with the English language. You may be the most fluent English speaker ever, written dissertations on Shakespeare, Jonson and Chaucer, but the first time you read an insurance policy you say to yourself "that sure looks like English, but damn it, it just won't parse!"
          • Sure. But that goes both ways. _If_ you know asm and C well, going from kernel code to GUI code has a lot of pitfalls (as does the opposite). Or going to numerical recipe code, or whatever.

            But fundamentally, code is code and rather than be intimidated you should start reading and playing with it. Even if you never become a hardcore kernel hacker, it's another world that's definitely worth jumping into and not nearly as scary as you think.

            Alan's Gearheads Only articles in Linux Magazine are a great way to start out.

            (FWIW, I posted mainly as a gedanken piece and not because I think you're way off base; sometimes you see a quote that just seems applicable to another conversation...)

            Sumner
    • Messing with OS X kernel code, eh? Ladies and Gentlemen, the iHack has landed.
  • by jarodss ( 243400 )
    "Kernel programming is by and large a black art that should be avoided if at all possible."
    Heh, I like that, so true.

    It's something to hang beside my copy of the 2.4.15 kernel source code, I had to print it, my boss had a good laugh at it when I showed him, we have a few guys in house who are on the cutting edge of everything they can be and were running 2.4.15, about half lost their work because they were on the bleeding edge.
  • I particularly liked this quote:

    ``Kernel code must be by and large perfect. A bug in the kernel could cause random crashes, data corruption, or even render the operating system inoperable. It is even possible for certain errant operations to cause permanent and irreparable damage to hardware, for example, by disabling the cooling fan and running the CPU full tilt.''

    Back in the days of the TRS-80, those of us comfortable with playing around with BASIC, Tiny Pascal, and Z80 assembly used to try to comfort friends who were just learning to program and were a little more than scared at breaking the computer with, ``Don't worry, you can make whatever mistakes you want; it's not like anything you do is going to break the hardware''. :-)
  • Sheesh... (Score:2, Insightful)

    From the posts here, you'd think the title of the article was "Look at the silly Keep Out page".
    Cmon guys its just a disclaimer. Given the potential audience, its not a bad disclaimer either. Traditional mac "classic" developers are used to doing anything they want with system extensions. If you've used MacOS9 and below, youre aware that there are a plethora of extensions out there that can cause all sorts of headaches...not all are freeware hobbiest projects.

    More than anything else, I see that page as a warning to those used to using extensions to trample all over Apple's system code and cause major stability issues in the process in MacOS (not OSX).
  • PDF version (Score:2, Informative)

    by gorillasoft ( 463718 )
    The pdf version [apple.com] is much easier to read through than the site.
  • I've been using Linux and Solaris more or less exclusively for the past three years or so, but I've never payed much attention to the internals of the kernel.

    If someone has just relatively basic programming knowledge of C/C++, what's a good way to start learning about kernels?

    I've got an old 486 not doing anything, and I was thinking about how I could start from absolute scratch and try and build a trivially simple kernel (and shell to communicate with it). Where should I start?

  • The disclaimer is out of sync with the substance of the documentation. I found the overview to be nothing more than a entry-level introduction, lacking in many critical details that would prove relevant to somebody actually writing the code. However, to be fair, I've rairly come across a decent kernel developer text, especially where BSD is concerned. The code seems to be the only documentation when it comes to kernel development.
    • Here's a quote from the ADC (Apple Developer Connection) newsletter:

      This first installment of Apple's new "Kernel Programming" book delivers high-level information about the Mac OS X core operating-system architecture, as well as background for system programmers and developers of device drivers, file systems, and network extensions.

      In short, this is only the first chapter of the book. I like that they're releasing it piecemeal, it's better than waiting for the whole thing to be written. So far they've done the "Is this for you?" bit and have just completed the overview. Apple is pretty good at writing documentation to describe how something works (within reason) rather than just it's API. IMHO, this will probably be a good doc to read when it's finished, even if you prefer a different kernel.

  • "For more information on basic operating systems programming, you should consider the texts mentioned in the bibliography at the end of this book."

    There are a few references to this bibliography, but I was unable to find it. I assume that this book is a work in progress and that part hasn't been posted yet. I didn't miss anything, did I? I would be interested in what books they recommend (actually, I would be interested in slashdot readers' recommendations, too).

  • Well there's almost no meat in that book yet :-(

    It would also be nice if the author and/or editor would learn the difference between "difference" and "dereference" which is wrong thoughout...
  • Holy crap. Is this supposed to be Apple's way of keeping down rookie programmers? Could Apple be brainwashing young programmers to join their cause???

While money can't buy happiness, it certainly lets you choose your own form of misery.

Working...