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
> - SHARK (and OFWGENCFG)
> 
> 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?

-Chuck