On Mon, 9 Dec 1996, Bill Studenmund wrote:

> All the stuff in /sys/arch is the M.D. stuff. Everything else is supposed
> to be M.I.

One exception to this seems to be init_main.c from kern (which contains 
the main() function), which seems to be replaced for x86's booting by NFS,
or that's how it appears, I haven't actually checked much into this.  I am
not positive, and haven't had a chance to explore this in-depth, but I
would suspect that the code at the beginning of main would need a special
version to handle any arguments that the mach microkernel would pass it...
but then again, since the mac68k port seems to take booter variables, I
assume in this fashion, I guess that's probably passed on to the init code
in /sys/arch.  I'll look at this more after finals.  :-)

> > 3.	What major sections would have to be replaced by Mach calls other
> > than the video display code, ADB code, MMU code, and SCSI code?  How bad
> > would the MMU part be?
> 
> Quite possably not too bad at all as you're supposed to let the microkernel
> deal with these things anyway! The hassle would be translating NetBSD stuff
> to microkernel calls. Also, I don't know how the microkernel advertises
> what devices it has (since if you do this right, it could run on the
> microkernel on a PPC, ix86, and whatever else the microkernel supports).

I'm looking for that particular bit of information.  I have two (huge)
manuals that I DL'ed about the Mach microkernel that detail basically
every single thing about the kernel-server interface, except that it
doesn't say anything about any devices except the clock.

> (FreeBSD has a port of the ext2fs fs now. It should make a nice lkm, or,
> for development work, you could compile it in. You just couldn't
> distribute that kernel)

I'll have to look into that.  That would probably save a lot of pounding
on the Linux code.  :-)

> I think all you'd have to do is have the tool chain make a binary
> (elf?) of the type the microkernel expects. Also, I think you'd want to
> include some of the processor-specific parts of /sys/arch, like the
> PPC-specific part of the powerpc port (it probably needs to be broken into
> chip-specific and platform-specific parts, but I don't really know).

I was just thinking about that.  The big thing that bothers me are those
handfuls of code in assembly language.  As I delve farther in, perhaps
I'll find some of those routines duplicated by mach IPC calls, but... the
others may still leave an unfortunate processor dependency.  We'll see.

> It might be that you need to make a "ppcmach" port. Among other things
> because I hope we eventually get a "direct" port too. But if things are
> done right, user-land binaries won't be able to tell the difference. :-)

Right.  As long as they both recognize the same types of binary headers,
the ML underlying should be the same.  Noteworthy exceptions include
anything that directly accesses the hardware, but I think X and dt both
work entirely through drivers now on the NetBSD side.  That'll be the fun
part, /dev/adb and /dev/grf#....

> The part which would scare me the most (reflecting my lack of experience)
> would be configuring the tool chain. If you can do that, you're set; you
> can compile from anything.

Well, the fact that MkLinux exists for the PowerMac is a huge step in the
right direction.  What has me stumped is getting bmake working.  (Getting
it to compile was enough fun.  :-)  I can't find the sys.mk file anywhere,
it's not in sys.tar.gz, nor in shar.tar.gz, nor in the includes.tar.gz or
is it headers.tar.gz....  Since the compiler would already be building
binaries in a format recognizable by the mach microkernel (elf?)... the
toolchain in that regard shouldn't be a problem.  BTW, anybody know if
there's an ELF compatibility option that could easily be compiled in to
eliminate the need to compile a new userland, at least during the
development process?  (That is, of course, assuming I get enough of it
working to mount a filesystem....)

> I think it's a great idea, though. I'd love to help out, but there are
> too many things in the queue first (like actually graduating!). :-(

Thanks for the moral support, anyway.  And as always, thanks for the 
suggestions. I can't promise that I can get anything working, but... I
figure it's worth hacking at for a while, and I'd much rather run NetBSD
than Linux on top of Mach.  :-)  In the meantime, I have a couple more
200+ page microkernel books to print.  :-)

Later,

 /---------------------------------------------------------------------\
|David A. Gatwood             And Richard Cory, one calm summer night,  |
|davagatw@mars              Went home and put a bullet through his head.|
|dgatwood@nyx.cs.du.edu              --Edwin Arlington Robinson         |
|http://mars.utm.edu/~davagatw -or- http://nox.cs.du.edu:8001/~dgatwood |
 \---------------------------------------------------------------------/