upvote

points

by rayiner5 hours ago |
comments
upvoteby blkhp194 hours ago|
next
[-]
I felt similarly. The learning curve was a tad steep, especially since I had never written a driver before, but once I figured out how to structure things and saw the system come alive, I grew to appreciate the approach IOKit takes.

With that said, I haven't developed drivers for any other platforms, so I really can't say if the abstraction is good compared to what's used by modern systems.

reply
upvoteby spijdar4 hours ago|
prev|
next
[-]
IOKit was actually built from the ground up for OS X! NeXT had a different driver model called DriverKit. I've never coded against either, but my understanding was they're pretty different beasts. (I could be wrong)

That said, indeed, the abstraction layer here is delightful! I know that some NetBSD devs managed to get PPC Darwin running under a Mach/IOKit compatibility layer back in the day, up to running Xquartz on NetBSD! With NetBSD translating IOKit calls. :-)

reply
upvoteby twoodfin3 hours ago|
parent|
next
[-]
There’s a great video of a NeXT-era Steve Jobs keynote floating around—I think the one where he announces the x86 port as NeXT was transitioning to a software-only company—where he specifically calls out DriverKit and how great it is.

Steve was not a developer but he made it his business to care about what they cared about.

reply
upvoteby steve19773 hours ago|
parent|
prev|
next
[-]
Funnily enough, there is a (different) DriverKit in macOS again now ;)
reply
upvoteby erichocean4 hours ago|
parent|
prev|
[-]
As I remember it, they were basically the same—but IOKit is C++ (with restrictions) because 3rd party developers didn't want to learn Objective-C.

But that's a hazy, 20 year old memory.

reply
upvoteby spijdar1 hours ago|
parent|
next
[-]
Yes, you're right! I'm just dolt who's never checked what a .kext on OS X actually is.

I had been under the impression that DriverKit drivers were quite a different beast, but they're really not. Here's the layout of a NS ".config" bundle:

  ./CG6FrameBuffer.config/English.lproj
  ./CG6FrameBuffer.config/English.lproj/Info.rtf
  ./CG6FrameBuffer.config/English.lproj/Localizable.strings
  ./CG6FrameBuffer.config/CG6FrameBuffer_reloc
  ./CG6FrameBuffer.config/Default.table
  ./CG6FrameBuffer.config/Display.modes
  ./CG6FrameBuffer.config/CG6FrameBuffer
The driver itself is a Mach-O MH_OBJECT image, flagged with MH_NOUNDEFS. (except for the _reloc images, which are MH_PRELOAD. No clue how these two files relate/interact!)

Now, on OS X:

  ./AirPortAtheros40.kext/Contents
  ./AirPortAtheros40.kext/Contents/_CodeSignature
  ./AirPortAtheros40.kext/Contents/_CodeSignature/CodeResources
  ./AirPortAtheros40.kext/Contents/MacOS
  ./AirPortAtheros40.kext/Contents/MacOS/AirPortAtheros40
  ./AirPortAtheros40.kext/Contents/Info.plist
  ./AirPortAtheros40.kext/Contents/version.plist
OS X added a dedicated image type (MH_KEXT_BUNDLE) and they cleaned up a bit, standardized on plists instead of the "INI-esque" .table files, but yeah, basically the same.
reply
upvoteby steve19773 hours ago|
parent|
prev|
[-]
From here:

https://news.ycombinator.com/item?id=10006411

"At some stage in the future we may be able to move IOKit over to a good programming language"

reply
upvoteby xenadu021 hours ago|
parent|
[-]
IOKit was almost done in Java; C++ was the engineering plan to stop that from happening.

Remember: there was a short window of time where everyone thought Java was the future and Java support was featured heavily in some of the early OS X announcements.

Also DriverKit's Objective-C model was not the same as userspace. As I recall the compiler resolved all message sends at compile time. It was much less dynamic.

reply
upvoteby geerlingguy4 hours ago|
prev|
next
[-]
And there are enough parallels to Linux's stack, I'm thinking about looking through the Linux on Wii project more and comparing how it handles fb issues in comparison. I loved reading this whole post, crazy how many OSes have now been run on the humble Wii!
reply
upvoteby steve19773 hours ago|
prev|
next
[-]
I guess having targeted multiple architectures and in the case of OPENSTEP also operating systems early on certainly helped.
reply
upvoteby phendrenad22 hours ago|
prev|
[-]
> I'm surprised by how well abstracted MacOS is (was).

Usually the difference between something being well-abstracted vs poorly-abstracted is how well it's explained.

reply