3 ms·

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

by rayiner 7mo 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.

geerlingguy 7mo 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!
spijdar 7mo 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. :-)
- erichocean 7mo 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.
  - steve1977 7mo ago
    From here: https://news.ycombinator.com/item?id=10006411 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"
    - xenadu02 7mo ago
      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.
      - pjmlp 7mo ago
        Mostly because they thought Objective-C wasn't going to land well with the Object Pascal / C++ communities, given those were the languages on Mac OS previously. To note that Android Things did indeed use Java for writing drivers, and on Android since Project Treble, and the new userspace driver model since Android 8, that drivers are a mix of C++, Rust and some Java, all talking via Android IPC with the kernel.
        lukeh 7mo ago
        There was also the Java-like syntax for ObjC but I don’t think that ever shipped.
      - lemoncucumber 7mo ago
        > there was a short window of time where everyone thought Java was the future Makes me think of how plists in macOS are xml because back then xml was the future
  - spijdar 7mo 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.
    - KerrAvon 7mo ago
      You're focusing on the executable format, which is very much not the driver model.
  - pjmlp 7mo ago
    Yes, also the same reason why Java was originally introduced, Apple was afraid that the developer community educated in Object Pascal / C++, wasn't keen into learning Objective-C. When those fears proved not true, and devs were actually welcoming Objective-C, it was when they dropped Java and the whole Java/Objective-C runtime interop.
- steve1977 7mo ago
  Funnily enough, there is a (different) DriverKit in macOS again now ;)
- twoodfin 7mo 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.
  - nxobject 7mo ago
    Yeah - even from the start, I remember NeXT marketing was spending a disproportionate amount of their time selling NeXT’s “object technology”, AppKit and Interface Builder, DPS as an advanced graphics model. It was good hunch from Steve, given how how modern NeXTSTEP feels in retrospect. For some reason, though, it means that people overlook how NeXT’s hardware was _very_ far from fast. You weren’t going to get SGI level oomph from m68k and MO disks.
    - lukeh 7mo ago
      Yup, even with a hard drive the m68k turbo slab was no speed demon. Wasn't too bad on HPPA though.
- pjmlp 7mo ago
  Driver Kit used Objective-C, and ironically it is back, as Apple gave the same name to the userspace driver model replacement for IO Kit.
  - jen20 7mo ago
    > ironically it is back, as Apple gave the same name to the.... This isn't that ironic - reusing old names where the trademarks are already owned etc is a pretty common thing.
blkhp19 7mo 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.
steve1977 7mo ago
I guess having targeted multiple architectures and in the case of OPENSTEP also operating systems early on certainly helped.
phendrenad2 7mo 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.
- shermantanktop 7mo ago
  I’d say it’s more about how much explanation is needed. There are cool abstractions that require explanation because they aren’t intuitive at first, and then it clicks. But usually if I find endless explanations of why indirection is better because it aligns with someone’s conceptual model, that’s to me a bad abstraction. Not because it’s leaky, but because it resists understanding.
MarceliusK 7mo ago
Once he could satisfy the expected interfaces well enough, the rest of the system seems to have been surprisingly willing to play along

by rayiner 7mo ago

geerlingguy 7mo 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!

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

erichocean 7mo 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.
- steve1977 7mo ago
  From here: https://news.ycombinator.com/item?id=10006411 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"
  - xenadu02 7mo ago
    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.
    - pjmlp 7mo ago
      Mostly because they thought Objective-C wasn't going to land well with the Object Pascal / C++ communities, given those were the languages on Mac OS previously. To note that Android Things did indeed use Java for writing drivers, and on Android since Project Treble, and the new userspace driver model since Android 8, that drivers are a mix of C++, Rust and some Java, all talking via Android IPC with the kernel.
      - lukeh 7mo ago
        There was also the Java-like syntax for ObjC but I don’t think that ever shipped.
    - lemoncucumber 7mo ago
      > there was a short window of time where everyone thought Java was the future Makes me think of how plists in macOS are xml because back then xml was the future
- spijdar 7mo 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.
  - KerrAvon 7mo ago
    You're focusing on the executable format, which is very much not the driver model.
- pjmlp 7mo ago
  Yes, also the same reason why Java was originally introduced, Apple was afraid that the developer community educated in Object Pascal / C++, wasn't keen into learning Objective-C. When those fears proved not true, and devs were actually welcoming Objective-C, it was when they dropped Java and the whole Java/Objective-C runtime interop.
steve1977 7mo ago
Funnily enough, there is a (different) DriverKit in macOS again now ;)
twoodfin 7mo 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.
- nxobject 7mo ago
  Yeah - even from the start, I remember NeXT marketing was spending a disproportionate amount of their time selling NeXT’s “object technology”, AppKit and Interface Builder, DPS as an advanced graphics model. It was good hunch from Steve, given how how modern NeXTSTEP feels in retrospect. For some reason, though, it means that people overlook how NeXT’s hardware was _very_ far from fast. You weren’t going to get SGI level oomph from m68k and MO disks.
  - lukeh 7mo ago
    Yup, even with a hard drive the m68k turbo slab was no speed demon. Wasn't too bad on HPPA though.
pjmlp 7mo ago
Driver Kit used Objective-C, and ironically it is back, as Apple gave the same name to the userspace driver model replacement for IO Kit.
- jen20 7mo ago
  > ironically it is back, as Apple gave the same name to the.... This isn't that ironic - reusing old names where the trademarks are already owned etc is a pretty common thing.

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

steve1977 7mo ago

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

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

shermantanktop 7mo ago
I’d say it’s more about how much explanation is needed. There are cool abstractions that require explanation because they aren’t intuitive at first, and then it clicks. But usually if I find endless explanations of why indirection is better because it aligns with someone’s conceptual model, that’s to me a bad abstraction. Not because it’s leaky, but because it resists understanding.

MarceliusK 7mo ago

Once he could satisfy the expected interfaces well enough, the rest of the system seems to have been surprisingly willing to play along