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.'"
Damn... (Score:1)
Re:No kidding (Score:3, Funny)
Re:No kidding (Score:2)
Re:No kidding (Score:2)
Re:No kidding (Score:2)
So if I, the "inexperienced hobby coder", change kernel code, fuck up, damage my machine, Linus will pay the bill? Or will he just say "Why the hell did you do this?"
Slashdot: News for l33t Linutix haxors.
I was going to read it... (Score:3, Interesting)
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
Re:I was going to read it... (Score:4, Insightful)
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.
Re:I was going to read it... (Score:3, Insightful)
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
Re:I was going to read it... (Score:2)
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!"
Re:I was going to read it... (Score:2)
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
Re:I was going to read it... (Score:1)
My favorite quote... (Score:2, Insightful)
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.
Heh...times are a'changing (Score:2)
``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)
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)
Learning the basics of kernels (Score:1)
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?
So far so weak (Score:2)
Be patient (Score:2)
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.
Bibliography? (Score:1)
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).
Wake me when it's done (Score:2)
It would also be nice if the author and/or editor would learn the difference between "difference" and "dereference" which is wrong thoughout...
wow (Score:1)