Mac OS 9 Discussion > Development & Programming

Mac OS nanokernel

(1/4) > >>

Protools5LEGuy:
https://en.wikipedia.org/wiki/Mac_OS_nanokernel


--- Quote ---The Mac OS nanokernel is an extremely simple operating system kernel serving as the basis of most PowerPC based system software versions 7 through 9, predating OS X. The initial revision of this software is an extremely simple, single tasking system which delegates most tasks to an emulator running the Motorola 68K version of the operating system. The second major revision supports multitasking, multiprocessing, and message passing, and would be more properly called a microkernel. Unlike the 68K-derived Mac OS kernel running within it, the PowerPC kernel exists in a protected memory space and executes device drivers in user mode. The nanokernel is completely different from the Copland OS microkernel, although they were created in succession with similar goals.
--- End quote ---

System 7.1.2—Mac OS 8.5.1


--- Quote ---The original nanokernel, and the tightly integrated Mac 68k emulator, were written by emulation consultant Gary Davidian.[4] Its main purpose is to allow the existing Motorola 68K version of the operating system to run on new hardware. As such, the normal state of the system is to be running 68K code. The operating system does little until activated by an interrupt, which is quickly mapped to its 68K equivalent within the virtual machine.

Other tasks may include switching back to PowerPC mode, if necessary, upon completion of the interrupt handler, and mapping the Macintosh virtual memory system to the PowerPC hardware. However, as the software is little documented, these might instead be handled by the emulator running in user mode.

This nanokernel is stored on the Mac OS ROM chip integrated into Old World ROM computers, or inside the Mac OS ROM file on disk on the New World ROM computers, rather than being installed in the familiar sense.
--- End quote ---

Interim development


--- Quote ---Progress after 1994 demanded additional functionality. A forward-looking architecture was introduced for PCI card drivers in anticipation of Copland OS, which supported memory protection. The Open Transport networking architecture introduced standardized PowerPC synchronization primitives. The DayStar Digital Genesis MP Macintosh clone requires kernel extensions to support multiprocessing. This evolution would later affect the overhaul to the nanokernel in Mac OS 8.6.
--- End quote ---


Mac OS 8.6 and later


--- Quote ---Mac OS 8.6's nanokernel was rewritten by René A. Vega to add Multiprocessing Services 2.0 support. PowerMacInfo (distributed in the Multiprocessing SDK) is an application that displays statistics about the nanokernel's operation.
--- End quote ---

René A. Vega's explanation of basic Mac OS architecture

https://groups.google.com/forum/#!msg/comp.sys.mac.programmer.help/tO0iuTNETGc/oTwfHPfuqXoJ


--- Quote ---In all Mac OS 9.x and earlier systems that ran with the first PowerPC machines, the system was built with a nanokernel. That
kernel and the original emulator was the brainchild of Gary Davidian, a superb engineer who developed a tiny piece of code to
create two protected contexts one for the 68K emulator and one for native (PowerPC) code, ensuring a seamless transition from 68K
based hardware to PowerPC. That 18 KB kernel handles address relocation, hooks for virtual memory, exception management, low level
I/O support, alignment handling and high performance instruction emulation.

Atop that sits the upper layers of the OS, I/O drivers, graphics, process manager, etc. There is no kernel layer above the
nanokernel, just managers and servers.



--- End quote ---

--- Quote ---I rewrote the nanokernel in OS 8.6, adding multitasking, multiple address space support, fully protected memory, multiprocessing
support, a high performance scheduler, enhanced power management. That increased its size to 50K (80K with full debugging
support). The upper layers didn't exploit much of that support in 8.6, though the notable change was the blue task blocking when
idle thence reducing battery consumption by 40% on laptops. Through the subsequent releases up to 9.x, more of the system used
those modern facilities as did in-house and 3rd party applications.
--- End quote ---


--- Quote ---> When designing a kernel, its authors can choose one of several design
> philosophies. If the kernel contains a lot of stuff in it, then it's
> called a monolithic kernel.

A good example is OS X. Mach, IOkit, BSD are pretty much integrated into a monolithic kernel.

> >Now here is my question:
> >
> >I understand the Mac OS X/Darwin has a nanokernel.

No. Mac OS X has a kernel by way of the integrated facilities.

> At first I was
> >under the impression that a nanokernel was a Unix specific thing,

Not really. Most unix systems have kernel functions integrated with the upper layers. A few unix system have a microkernel
underneath them. mklinux is one such system.

>
> >then after some very quick research on the web, I concluded that no,
> >prior Mac OS's make use of a nanokernel also.

The nanokenrel was used starting with system 7 on 6100s.

> > In particular, OS 9.1 makes use of a nanokernel.

Yes.

> Mac OS X uses the Mach kernel, developed at Carnegie-Mellon. It's a
> microkernel -- it implements some stuff, but leaves a lot of stuff to be
> implemented outside of the kernel.

Yes, but at this point OS X integrates many more functions into the kernel.

> Mac OS 9 uses a nanokernel. The nanokernel implements a very small
> number of things -- basically the lowest level of interaction with the
> processor and other components of the system is in the nanokernel,

The nanokernel implements a  fair amount: multitasking, multiprocessing support, multiple virtual address spaces, memory
protection, server based VM, server based I/O, address space management kernel calls. There are over a hundred kernel calls.

> >So, what I am interested in, is this: When you run Classic mode inside
> >of OS X, you are 'taking' in some way from a bootable 9.1 OS (I guess
> >usually) that sits on another partition on your hard drive. That
> >bootable 9.1 OS must also make use of a nanokernel. Does it make use
> >of it while you are using Classic mode? It would have to in some way,
> >correct?

What is done (and this is clever), is the kernel SPIs are used as an abstraction layer. The native nanokernel is replaced by a
shim which either directly implements kernel calls or uses OS X services to implement other kernel calls. It's a little bit more
complicated than this, but essentially this is what takes place.

>  I believe that the Mac OS 9 nanokernel is not involved in
> the Mac OS X Classic action.

Insofar as the native code is not used, but the SPI remains.

> By replacing interactions with the
> nanokernel with interactions with the Mac OS X kernel, the Classic
> environment becomes just another process running under Mac OS X.

Mostly so. There are other high level issues such as coordinating window drawing, unifying high level event management, drag and
drop clip board management. One important thing is under OS 9, Mac OS (that which most people interact with) is just another
process running as a task by the nanokernel.

> >How does Classic mode work? Is it, from the programming standpoint,
> >just an entire 9.1 OS running inside of OS X?

Mostly with fancy plumbing to bridge services between the two OSs, and a pseudo kernel supporting the nanokernel's SPI.

> (Meeroh says)

> Basically, this is my understanding:
>
> Mac OS 9 structure is
> Applications & Drivers -> System -> Nanokernel
>
> Mac OS X structure is
> Applications -> System -> Kernel & Drivers
>
> Mac OS X with Classic structure is
> Mac OS 9 Applications & Drivers -> Mac OS 9 System in Classic -> [abstraction layer] Mac OS
> X Kernel and Drivers
>

I added the abstraction layer. Also, to makes things run faster there are various virtual machine-like assists in the mach kernel
for classic.

Classic runs surprisingly well, up to 90% of native performance on X if you throw a lot of RAM into your machine to accomodate the
combined working sets of the two systems.
--- End quote ---

https://groups.google.com/forum/?hl=en#!topic/comp.sys.mac.programmer.help/3NK-jAdmOqg

nanopico:
Glad to see this all put together in one spot.

ELN:
Hi all,

I thought I should write up a brief discussion of the Mac OS Nanokernel. This is a very early draft. Once it has matured here a bit, I will set up a corresponding page on my cdg5 wiki (github.com/elliotnunn/cdg5/wiki).

First up: nanokernels aren't really a thing. A microkernel is an operating system kernel that delegates a great number of OS functions to userspace processes, which have no (or less) direct access to hardware and which follow the normal rules for process preemption, etc. The Nanokernel (I'll capitalise the name of the Mac OS one) does something like this. Hardware interrupt handling and a bunch of other stuff is farmed out to a single "blue" task, which contains the "System 7-style" Mac OS environment. Other tasks were spun off from within the blue task, and could be scheduled alongside the blue task or on a second processor.

The Nanokernel came in two quite different versions, and shipped in a few different ways. Version 1.x shipped with all beige Power Macs and in some early releases of the NewWorld ROM (I am not sure which ones). Version 2.x shipped inside later NewWorld ROM releases, and inside a "krnl" System file resource in 8.6 or later. On OldWorld machines, some bizarre kernel-replacement process takes place surprisingly late in the boot process. Worse still, from 8.6 to at least 9.0.4, kernel replacement seems to be optional.

ELN:
I think I'll just keep posting to this thread, and collate all this info at a later date. Nanopico and I have been continuing our email exchange. While he works on the Trampoline and System file stuff, I'm hacking away at the Nanokernel.

After testing out IDA (what a mess) and trying to wrestle with the GNU Binutils, I have settled on rolling my own disassembler and static kinda-analyser. It is called Statin, and it uses Capstone as its disassembly backend and Networkx to maintain a directed graph of control flow. Check it out: https://github.com/elliotnunn/cdg5/blob/master/statin.py

At the moment Statin is hardly a general solution to anything, but I think that it has some potential. I am using it to hack on version 02.28 of the Mac OS Nanokernel, which as far as I know was the final release. I can only find it in Mac OS ROM version 10.2.1.

A quick update on what shipped when. Nanokernel v2 (the rewritten version that I am interested in) was released in mid-1999 as part of Mac OS 8.6. Its chief new feature was the ability to encapsulate the cooperative Mac OS environment inside a single preemptively scheduled "blue task". Other preemptive tasks could then be spun off from the blue task using version 2 of the Multiprocessing Services API, and could share the CPU with the blue task. Not bad for a point release.

On OldWorld systems, which already have Nanokernel v1 in ROM, the blue task loads Nanokernel v2 from a System file "kern" resource early in the boot process. The new Nanokernel gets executed and performs some shenanigans to squeeze out the old Nanokernel, then resumes the normal boot process. If this patch process fails, then boot can still continue with the old nanokernel. This is why Sheepshaver (which has only ever worked with Nanokernel v1) can boot 8.6 and 9.0 (and, rumour has it, 9.1). By 9.2, this was definitely no longer possible, and Nanokernel v2 was a hard requirement (but do remember that the only OldWorld machines on which 9.2 officially ran were beige G3s). This is why people talk about Sheepshaver needing to emulate an MMU to run the final releases of 9 -- because Nanokernel v2 absolutely needs hardware VM. In fact, the Sheepshaver devs had to do a considerable amount of hacking just to get v1 to run without an MMU.

On NewWorld systems, things are thankfully a bit simpler. Nanokernel v2 occupies the same place in the ROM-in-RAM image that Nanokernel v1 used to -- up to about 100K at offset 0x310000. Mac OS ROM files versioned 1.4 or earlier shipped with Mac OS 8.5.1 or earlier and contain the old Nanokernel. Files versioned 1.6 or later shipped with Mac OS 8.6 or later and in "Mac OS ROM Update 1.0", and contain the new Nanokernel. But Nanokernel v2 really became useful with the release of the first Power Mac G4s, which were dual-core and AltiVec-equipped, a few months after OS 8.6. Side note: the Mac OS ROM file in these machines, versioned 2.5.1, is a bit of an oddball. It introduced the "parcels-based" format used in subsequent releases and by the Classic environment, and it has quite a large number of extraneous PEFs appended outside its compressed region, making it quite large.

The binary code in a System kern resource is the same as what you would find in a NewWorld ROM image. You can swap them over (I tried it). Anyone want to give Nanokernel 02.28 a go in an OldWorld machine? I'm pretty sure you'd be the first.

DieHard:
I read and re-read the last post 4 times !

If this shit doesn't absolutely fascinate you, then you are brain dead.  This is awesome stuff.  I doubt the Apple camp ever thought anyone would dissect the code or unveil/crack open the secrets they locked away in the Black Box.

You guys are amazing !   The level of tenaciousness is unsurpassed.  Please keep going !  The Mac OS 9 2017 modified nanokernel and System ROM 11.0 is set to be released before Feb 2017 :)

Navigation

[0] Message Index

[#] Next page