Re: Cross-compiler OK, Hurd boots! Next project - fix SMP!
> Enter into the mixture this OSkit-mach, and I'm not sure where to
> get started.
It is my recommendation not to try to make gnumach SMP support work, and
just go with oskit-mach. There is a good bit of work still needed, but the
groundwork is there. Importantly, the oskit has code that already works to
support the low-level SMP support features of the BIOS and APIC and so
forth. I started work on making oskit-mach use this when built with
--enable-smp=N with N>1, and I think it compiles, but I have not worked
on it in a long time.
I cannot recommend too highly the benefits of cross-debugging with gdb over
a serial line from your cross-compile development machine to your test
machine. The oskit makes this easy in all oskit kernels, so oskit-mach has
it. I don't think this is working in gnumach (not that it's horribly
difficult to add). But I take any chance to plug oskit-mach, since I wrote it.
> That is, is there a general preference on which mach is preferred? The
> stuff I have read seems pretty out-of-date.
> 1. Can gnumach and OSkit-mach coexist in the Hurd partition?
Totally. Remember that these kernels are microkernels, and the contents of
the filesystems and so forth are entirely the business of the Hurd tasks
that run on top of the microkernel. Both kernels are multiboot kernel
images, so GRUB treats them the same. Both kernels provide the precise
same system call and RPC interface to the software that runs on top of
them, except in the details of what devices are available to open and
exactly how those devices behave. (There are probably some loose ends I
knowingly broke and didn't get around to fixing, e.g. I would not be
surprised if the mach_i386.defs RPC interfaces don't all work in oskit-mach).
All it means to install either kernel is to put the kernel image (or a
gzip'd version of it) in a file and set up GRUB to boot that kernel. The
GRUB setup to boot the Hurd is the same whichever kernel you use. The
kernel command line options that oskit-mach accepts differ somewhat from
gnumach's; it has a bunch of common code for options that most oskit
kernels have. But I believe that oskit-mach also accepts all the gnumach
options.
So in short, build oskit-mach, install it in /boot on your test machine and
try your existing Hurd boot sequence with nothing changed but /boot/gnumach
-> /boot/oskit-mach. It might well Just Work. If you are fond of using
the VGA console of your Hurd machine as supported by the kernel's built-in
console terminal emulation device, you will not like oskit-mach so much
right off. You may also notice it lacks the appropriate input devices
necessary to X to work. But that is just motivation to get hacking so
you're ready to get those drivers implemented in the oskit!
> 2. OSkit-mach gets ripped on for being slow, but at the same time then
> the microkernel can be smaller. Would SMP gains outweigh the
> performance hit?
I don't know what "ripping" you are talking about. The core Mach code is
slow, and that is a problem, but it's the same problem for gnumach and
oskit-mach. oskit-mach lacks some features, like a real console device and
real serial devices. But the device drivers it does have (disk and net)
are newer Linux drivers than gnumach's Linux drivers and generally better.
I don't know of any other complaints about slowness of oskit-mach vs gnumach.
> 3. Any suggestions or comments?
If you decide to try to make SMP work in gnumach, you must be insane. So
I'll assume you're going with oskit-mach. ;-) There are two things to do
first: compile oskit-mach yourself and get it working in uniprocessor mode;
and compile the oskit's smp example kernel yourself and get it working on
your hardware. The prerequisite for both of these is to get the oskit
source and compile it yourself (use --enable-debug and make sure it
compiles with -g).
You can compile the oskit in your hurd cross-compilation environment if you
want to. But you can just as well build it natively on your development
machine (assuming it's an x86, Linux or *BSD); i.e. just "../configure" in
your build directory (never try to build anything in its source directory).
You can configure and build oskit-mach using the native compiler and oskit
installation instead of the i586-gnu cross-compiler too (this also works
with gnumach). Do whatever is convenient for you. If memory serves, you
want to use "CFLAGS=-g ../configure" to configure oskit-mach so that it
will compile with -g for debugging.
When you compile with debugging, you'll get a huge executable with symbols.
You can strip the copy you put onto your test machine to boot from, with
"strip" or "objcopy -S" to make the copying quicker. But you want to use
the original file with complete symbols when you run gdb on your
workstation (to connect to the test machine's gdb serial line with "attach
/dev/ttyNN"). You should experiment some with using gdb across a serial
line on the oskit example kernels before beginning to hack on oskit-mach.
In the meantime, I'll try to make sure that oskit-mach compiles with the
current oskit and with --enable-smp, though I am not in a position right
now to test that the kernels actually work. When you are ready to start
hacking, we can talk about the things that still need to be implemented for
oskit-mach's SMP to work right.
Reply to: