Mac OS X provides a kernel extension mechanism as a means of allowing dynamic loading of pieces of code into the kernel, without the need to recompile. These pieces of code are known generically as plug-ins or, in the Darwin kernel, as kernel extensions or KEXTs.
Introduction to Kernel Extension Concepts
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
…are these fundamentally different, if at all, from loadable kernel modules?
I suppose the fact that upgrading your kernel doesn’t break every 3rd-party driver in existence, unlike Linux?
Just a thought.
I suppose the fact that upgrading your kernel doesn’t break every 3rd-party driver in existence, unlike Linux?
But that’s not a fundamental difference and I wasn’t thinking about the Penguin Kernel.
That’s really only when you upgrade to a major revision (2.4 to 2.6) and it isn’t exactly unique to Linux either.
Anyway, I don’t see the point of this particular entry; is it supposed to be like the scene in Pulp Fiction? Are we supposed to be typing variations on “Kexts? Sheesh, get away!”
is it like Apache?
Pwnt
No, they are known generalically as modules. In the Darwin kernel they are the same, woth a different name. In neiher cases are they called plugins.
Now… If I found thhe nvidia (NVDA) kernel extensions for osx86… I’d be happy
It’s rather difficult to get a proper .kext driver done. This includes XML files, matching dictionaries and other weird stuff of where you don’t know where to just start with a blank editor window. There are examples, though, and with much help from these (read lots of verbatim copying without understanding the reasoning, at least in the beginning) and line-by-line reading through header files, it is possible to eventually get done.
Then, the choice of EC++ as language is a bit weird as well, leading to ABI issues (mostly masked by the OS). They do work around the fragile-base-class problem though, and you can pick the method tables of the versions you need (at least in user space, forgot about the kernel details). So this is more odd on a large scope, adding yet another language to the complete OS X skill set.
Finally, detail implementation can be .. complicated, to say the least. Give the serial driver base classes (and how they’re side-hacked into the xnu BSD core) a look and post a short sum-up on how they work in here
On the up-side, the core developers hang around on the mailing lists, and qualified questions will get instant qualified answers, sidetracking the whole ADC bullshit. This will well save your day in any reasonably complex project.
Rich
The matching dictionary and plist stuff really is the easiest part of driver developement. For a driver newbie, it’s much harder to actually know what you have to _do_ in a driver. Of course, that stuff is the same as in Linux, BSD or wherever, but I still have no idea how to actually make the hardware do what I want it to do (except for really trivial cases).
I’d like an article “System agnostic driver programming for dummies” or the like.
> The matching dictionary and plist stuff really is the easiest part of driver developement.
You really think so? I’ve done some OS X lately involving barcode readers, a heap of Linux stuff before (mostly low-level comm stuff, SPI, Ethernet & PHY, serial) and classic MacOS (mostly USB networking) and usually the hardware (given that you have specs or someone to ask) is usually understandable. Weird at times, but understandable. But when the IOKit docs say “this parameter is a matching directory for the iterator”, I think “well, I want to match _my_ device, but what on earth do I have to put in there now”. This is where the example browsing begins.
> For a driver newbie, it’s much harder to actually know what you have to _do_ in a driver.
> I’d like an article “System agnostic driver programming for dummies” or the like.
It’s rather simple. You tell the device what to do (on a basic scale). Then you wait for it to complete. You get the interrupt and post a second level interrupt. There, you deal with what to do next. Because you can’t wait for all that in a thread, get used to state machines and basic sync primitives to feed them.
While all of the driver development can be _hard_, especially due to considerations beyond the basics, I’ve found Linux to be the most understandable platform (because in the end, you have to understand everything anyway, and the least abstractions you have to think around, the least overall overhead you have).
I know there are driver toolboxes for Windows that give you the illusion of easiness, but somewhere you’ll miss a glitch hidden behind all that prettiness and then poor M$ (on _that_ record) gets all the BSOD-blame.
I guess we’re seeing rather high quality drivers for the Mac much because of political issues, where the real cheapskate shops don’t consider the Mac to be a viable platform. Mac-centric vendors generally have dedicated Mac coders and big shops can afford to keep a few of these, too (*). And then, maybe it’s just _so_ complicated that by that fact the chaff gets weeded out anyway (**).
Rich
(*) Unfortunately I have seen a _very_ big south-eastish asian vendor employing guys with names that indicate they’re from a popular outsourcing (_very_ large south asian) country. They’ve been posting on a certain list regarding IOKit/kext issues – and they positively hadn’t got _ANY_ clue on what all this stuff was about.
(**) One quirk on the classic Mac, for example, is that OpenTransport will pretty much re-enter and post callbacks at _any_ time – you get to figure this out the hard way and if you’re not able to understand that and put it in context with your project, you will not get a driver that works for more than 5 minutes.