> 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.
