Subject: Re: Split or don't split arm32?
To: Todd Vierling <>
From: Chuck Silvers <>
List: tech-ports
Date: 12/23/2000 09:36:53
On Fri, Dec 22, 2000 at 12:30:37PM -0500, Todd Vierling wrote:
> : But why do we need to split ports?
> It's _possible_ to make these arm32 machines share a GENERIC in the same way
> that it's _possible_ to make mvme68k and amiga share a GENERIC.  The base
> CPU hardware is there, but everything else is different.  This doesn't mean
> it's the right way to go about the ports.

this doesn't mean it's the wrong way to go about supporting these kinds of
hardware either.

> The Shark, for instance, is the only arm in the bunch that uses ofisa, and
> _all_ its devices are attached to ofisa.  Likewise, only the RiscPC uses
> vidc and podulebus, and only the CATS and EBSA boards have i386-PC-style IO
> glue.

ok, so the podulebus stuff should go in sys/dev/podulebus so it can be shared
between RiscPC and arm26.  does anything else use ofisa?  that would go in
sys/dev/ofisa then.  I imagine there's not much CATS-specific code to deal
with i386-PC-style stuff since it should all be in sys/dev/isa already.
how much device code is really specific to any arm32 hardware?

> Of the five main machine types currently in arm32, I see three major
> hardware infrastructures that probably do warrant having their own MACHINEs:
> - A7000 and RISCPC
> - CATS and EBSA285
> These three groups share much of their hardware glue and attachments, and
> likely could have GENERIC kernels per-MACHINE quite easily.

what's the advantage of having three different "GENERIC" kernels for these
three classes of hardware, vs. having three non-"GENERIC" kernels for them
like we do now while also allowing for the possibility of a unified kernel
which would support all three?

I only have a Shark currently, but if I had one of the other kinds of machines
too I would find it convenient to build a unified kernel for them, so that
I could build one kernel to do testing instead of two or three.  what's so
wrong about that?