← Back to context

Comment by rayiner

5 hours ago

Not only is this an insanely cool project, the writeup is great. I was hooked the whole way through. I particularly love this part:

> At this point, the system was trying to find a framebuffer driver so that the Mac OS X GUI could be shown. As indicated in the logs, WindowServer was not happy - to fix this, I’d need to write my own framebuffer driver.

I'm surprised by how well abstracted MacOS is (was). The I/O Kit abstraction layers seemed to actually do what they said. A little kudos to the NeXT developers for that.

11 comments

rayiner

Reply
blkhp19  4 hours ago

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.

spijdar  5 hours ago

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. :-)

  • twoodfin  3 hours ago

    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.

  • erichocean  5 hours ago

    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.

    • spijdar  1 hour ago

      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.

geerlingguy  5 hours ago

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!

steve1977  4 hours ago

I guess having targeted multiple architectures and in the case of OPENSTEP also operating systems early on certainly helped.

phendrenad2  2 hours ago

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