upvote

points

by erichocean4 hours ago |
comments
upvoteby spijdar1 hours ago|
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|
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