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

Re: porting to other architectures (68k no mmu family)



On Sat, 09 Dec 2000 22:40:36 +0100, the world broke into rejoicing as
Farid Hajji <farid.hajji@ob.kamp.net>  said:
> > Pardon the inane question, but how possible would it
> > be to port Hurd to processors like
> > 68328/68EZ328/etc... (yes, palm pilots...) ?
> > 
> > One would start with the mach microkernel right?
> Sure, porting Mach is absolutely necessary, as far as the Hurd
> is concerned. But the Hurd requires a lot of resources right
> now, and I doubt that palmtops provide enough RAM right now.
> 
> Other version of Mach support more that just i386. For example,
> osfmk (http://www.mklinux.org/) supports HP_PA as well and
> rtmach supports alpha, i386, luna88k, parisc, m88k, mips.
> It was done before, so doing this for gnumach/oskit-mach should
> be possible as well.

Another good place to look would be <http://xmach.org/>; that
is apparently reasonably active in building a BSD "user space"
on top of Mach.

Distinguishing it from Hurd would be that:
 - they're actively trying to support multiple architectures,
   trying to include IA-64;
 - xMach was originally based on Lites
 - the plan appears to be to assimilate the OpenBSD user space
   much as Hurd is working to assimilate the user space of
   Debian/Linux
 - they don't yet do multiserver stuff, but plan to

> > I've been testing/debugging uClinux for about a year
> > now and came across an article (via slashdot)

> The slashdot article is a bit skewed ;-)

_ALL_ slashdot articles are "a bit skewed" :-)

> > mentioning Hurd and embedded devices. I had read about
> > Hurd before and it seems like it might have some
> > interesting advantages over linux for embedded devices
> > (highly configurable and able to be small).

> Look at RTEMS, if you're interested in kernels for embedded
> devices. RTEMS supports a lot of architectures and it's free
> software too:
> 
>   http://www.oarcorp.com/RTEMS/rtems.html

The Cygnus ('now a division of Red Hat Software') eCOS project
should also be relevant; see:
 <http://sourceware.cygnus.com/ecos/>

The act of splitting things into Microkernel + multiservers introduces
some overhead, so that I'd expect a small Hurd system to have a greater
"footprint" (whether in terms of RAM or disk) than Linux. The notion
that Hurd would be more suitable for embedded applications seems
extremely wishful to me.  

RTEMS, eCOS, Inferno, vSTa, EROS, AMX (what PalmOS runs on top of),
all would seem to me to be more relevant to embedded applications
than Hurd, certainly in the short term, and likely even longer
term.

The merits of the microkernel/multiserver Hurd design are not
going to manifest particularly strongly in small systems, but
rather in that they would make it possible to build bigger,
more complex systems that are some combination of 
 [faster | more robust | easier to manage]
but this requires that you move to "large complex" systems,
and away from the more spartan approach usually taken for
embedded systems...
--
(concatenate 'string "cbbrowne" "@ntlug.org") <http://www.hex.net/~cbbrowne/>
If a hole in the street is a manhole, is a hole in a man a streethole?



Reply to: