[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Cross-compiler OK, Hurd boots! Next project - fix SMP!



Great, thanks for the info. My project this week will be to build the
oskit-mach microkernel and start scoping it out. I have already browsed
a good bit of info on it, and suspected that it might be the way to go.

Roland McGrath wrote:

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

Heh, right now I have a HP 700/60 dumb terminal on my serial line, and my
cross-compile development machine is my test machine. However, I have a
four-way selector switch on the serial line, and and my old 486 laptop has
gdb loaded ( With Debian 2.0! ) heh. That should work ok. I'm a little short
on desk space though...

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

Yeah, as far as the speed thing goes, who cares right now. If I want
speed I just boot up Linux, I think the cool thing about Hurd is that
in the future it may be potentially much easier to optimize than a
big monolithic kernel. Right now the main concern is just making
it run. The more cruft that can be moved into oskit the easier it
becomes to really optimize the kernel itself.
    Consoles - well I do like my ^[[1;31mColor^[[0m but that can wait.

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

Duly noted. As Ren said, "It is not I who am insane... it is I who am mad!" But
luckily I don't seem to have space madness yet, so I'll give oskit-mach a whirl.

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

Ok, I'll get going on this. I'll post a progress report in a couple days.

Thanks for the tips!
-Doug

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


Reply to: