how to port

[Samuel Rydh]

On Wed, Oct 01, 2003 at 07:21:02AM -0700, Andrew Musselman wrote:
> I would like to contribute if I can; do you have any good how-to's on 
> what needs to be changed when porting from linux to OSX/Darwin?  I have 
> some Apple doc's, but do you have anything else?

Well, the main problem is porting the kernel module.

The rest is just ordinary porting (missing headers etc.). Actually,
the rest of the code used to compiled once upon a time so there
should be no big problems in this area (of course, OSX needs some
speical support for networking etc).

As for the kernel module, the amoung of code needed
is quite small. However, it is technically complicated
and insights into how a unix kernel handles memory mappings
are required. A good understanding of the PowerPC MMU
is also very important.

More specifically, what needs to be done is:

i) Fixing the 'mol userspace' <-> kernel module (IOKit driver)
interface. MOL uses an ioctl interface under linux. OSX uses
a more complicated model based upon mach ports. A test selector
has already been implemented but it needs to be extended to all
ioctls.

ii) MOL needs to own a range of virtual segment IDs (VSIDs).
This require some sort of hack, possibly an on-the-fly
kernel patch. To get started, one could examine the OSX algorithm
for VSID allocation and just steal VSIDs from the end of the free
range. Of course, OSX will crash when OSX and MOL uses 
the same VSIDs but that ought to take a day or two since
the number of available VSIDs are immense. Obviously this
would not be the final solution...

iii) MOL does not wire MOL RAM pages. This means that MOL needs
to be told whenever a RAM page (owned by the userspace
process) is switched out in order to flush it from
MOL owned VSIDs. Under linux, this is achieved through
a hook of the flush_tlb_page(). Somethink similar
could probably be done under OSX.

iv) The flushing of PTEs from VSIDs needs locking (on SMP systems).
The lock can only be taken from non-faulting memory (i.e. BAT mapped
or with the MMU off).

v) I'm not sure MOL and OSX can easily share the same PTE hash. Linux
only uses it as a cache so PTE evicts are harmless. I believe OSX
uses a more complicated model though. It might be simplest to use
a private PTE table for MOL. It costs some wired continuous memory
though...

vi) The OSX kernel module (IOKit driver) can't easily access the
RAM of the MOL userspace process. Under linux, this space is mapped
into the kernel. This is not the case under OSX however. The MOL
kernel module primarily accesses the virtual RAM in order
to do emulated PTE lookups. (This is not a big problem; either
get_user() type of calls could be used to copy the relevant PTEGs from
userspace or the lookup could be performed in the low-level asm
code rather than from the C-code).

vii) The transition between the low-level asm part (where
MOL completely owns the CPU) and the C-level kernel module
code needs some work. Under linunx, a trampoline (or a faked
syscall) is used. Under OSX, we might have to do a full userspace
return from the low-level asm part and then invoke the C-level
stuff through the mach port interface.

viii) MOL needs to be able to page in userspace (RAM) pages.
Under linux, MOL essentially contains a copy of the kernel
page-in code. It is possible to do this completely without
relying on kernel internals though. Basically one would
have to access the RAM page in question from userspace (causing
the page in) and then lookup the physical page through a PTE
walk (or by calling a suitable kernel function). This would
be more expensive than the linux solution but the overhead
of page-ins are more or less neglible under MOL/linux so
this extra overhead might not matter that much.

Cheers,

/Samuel