5 ms·

Apple has some weird history with doing crazy things with 32b/64b stuff just because they can - back in the Intel 64 early days they ran a 64-bit kernel that lo

Apple has some weird history with doing crazy things with 32b/64b stuff just because they can - back in the Intel 64 early days they ran a 64-bit kernel that loaded 32-bit device drivers. I don't know if anyone has still figured out the how and why of it!

brigade 7y ago
They didn’t load 32-bit drivers in a 64-bit kernel; rather they ran a 32-bit kernel that supported 64-bit userspace processes.
- exikyut 7y ago
  That's even crazier. How and why??
  - wtallis 7y ago
    Apple started working on 64-bit application support back when they were still on PowerPC, where they only had 64-bit for desktop processors, not laptops. Then the first round of Intel Macs had 32-bit Core Duo processors. Less than a year later the second round introduced 64-bit Core 2 Duo processors that were pretty much a drop-in replacement, and at the time it certainly didn't make sense for Apple to overhaul their EFI, kernel and drivers with a 64-bit transition only 9 months after switching from PPC to x86. Support for 64-bit GUI applications on OS X didn't arrive until 2007, a year after Intel Macs started using 64-bit processors. Support for running a 64-bit kernel arrived in 2009, and only for machines that had 64-bit EFI firmware. In 2012, Apple dropped support for the machines that had 64-bit processors but used 32-bit EFI, so from that point on they were handling the 64/32-bit mix the same as other operating systems.
  - lgg 7y ago
    When the first 64 bit Macs shipped none of the software was 64 bit clean. Even if the kernel source code had been 64 bit clean, it would have broken support for all the the 3rd party 32 bit drivers that existed. So the kernel switched itself in 32 bit virtual mode, though some parts of the pmap layer understood 64 bit page tables in order to manage the 64 bit physical address space. While the kernel could not see all of memory, it did not need to, it could map any apertures it needed in by manipulating its own page tables. At that point it is pretty trivial to setup a 64 bit address space for a process. The kernel could not directly map all of virtual address range of the process at once, but it already had the pmap and aperture management code to deal with that. That decoupled 64 bit user space bringup from the 64 bit kernel port. The first release that supported 64 bit processes did not have 64 bit UI frameworks, just the C library and some low level posix functionality, but it allowed scientific code that benefited from more memory to run.
- blinkingled 7y ago
  You may be right but I remember both of those things - supporting 64-bit apps on 32-bit kernel and loading kexts that didn't bit-match the kernel. Long time ago so not sure.
  - deleted 7y ago
    [deleted]
  - sigjuice 7y ago
    Non-matching kexts was never a thing.

brigade 7y ago

They didn’t load 32-bit drivers in a 64-bit kernel; rather they ran a 32-bit kernel that supported 64-bit userspace processes.

exikyut 7y ago
That's even crazier. How and why??
- wtallis 7y ago
  Apple started working on 64-bit application support back when they were still on PowerPC, where they only had 64-bit for desktop processors, not laptops. Then the first round of Intel Macs had 32-bit Core Duo processors. Less than a year later the second round introduced 64-bit Core 2 Duo processors that were pretty much a drop-in replacement, and at the time it certainly didn't make sense for Apple to overhaul their EFI, kernel and drivers with a 64-bit transition only 9 months after switching from PPC to x86. Support for 64-bit GUI applications on OS X didn't arrive until 2007, a year after Intel Macs started using 64-bit processors. Support for running a 64-bit kernel arrived in 2009, and only for machines that had 64-bit EFI firmware. In 2012, Apple dropped support for the machines that had 64-bit processors but used 32-bit EFI, so from that point on they were handling the 64/32-bit mix the same as other operating systems.
- lgg 7y ago
  When the first 64 bit Macs shipped none of the software was 64 bit clean. Even if the kernel source code had been 64 bit clean, it would have broken support for all the the 3rd party 32 bit drivers that existed. So the kernel switched itself in 32 bit virtual mode, though some parts of the pmap layer understood 64 bit page tables in order to manage the 64 bit physical address space. While the kernel could not see all of memory, it did not need to, it could map any apertures it needed in by manipulating its own page tables. At that point it is pretty trivial to setup a 64 bit address space for a process. The kernel could not directly map all of virtual address range of the process at once, but it already had the pmap and aperture management code to deal with that. That decoupled 64 bit user space bringup from the 64 bit kernel port. The first release that supported 64 bit processes did not have 64 bit UI frameworks, just the C library and some low level posix functionality, but it allowed scientific code that benefited from more memory to run.
blinkingled 7y ago
You may be right but I remember both of those things - supporting 64-bit apps on 32-bit kernel and loading kexts that didn't bit-match the kernel. Long time ago so not sure.
- deleted 7y ago
  [deleted]
- sigjuice 7y ago
  Non-matching kexts was never a thing.