In article <44032897.1050901@tadpole.com>
garrett_damore@tadpole.com wrote:

> There was some note on ICB that a few other bits, /usr/mdec are machine
> dependent as well.  It was suggested that we could split base.tgz into
> base and base-md.tgz.  Then only the truly machine specific bits would
> need to be non-shared.

Yeah, but this makes sysinst a bit complicated, and some people on
architectures which have only one ${MACHINE} on its ${MACHINE_CPU}
might complain?
(if we'll support x86 mac, the situation could be better ;-)

>   etc.tgz probably needs to remain machine
> specific because of ttys, but I would *love* to have the rest of it
> (especially the majors and MAKEDEV bits) to be the same so that you
> would have the same major numbers across all the same ${MACHINE_CPU}.

MAKEDEV should be compatible, but it also has many historical reason,
unfortunately.

> > - disklabel, which may have some compatibility stuff with the "native" OS
> >   (OMS400 requires MBR support but current evbmips doesn't have it BTW)
> >   
> Yeah, but there is no disk support yet either -- i.e. you probably need
> compact flash & pcmcia to work first.  right now we don't even have that.

I haven't tried yet, but if ehci at pci works, sd at umass should work.
The firmware supports booting from USB storage devices. 

Anyway, we should also think about some MI (not only evbmips)
disklabel handling. (wedge can handle this?)

> > But in this difinition we'll have too much ports even for
> > a rare single architecture, so evb* ports cover all such machines.
> >   
> yes, except one definition i've heard for evb* ports is "Evaluation
> boards".  There are production boxes that share so much in common that
> it is silly to have them have their own port -- e.g. MTX-1 and OMS400
> are not eval boards at all, but are basically derivative designs.  Right
> now they are in evbmips even though they're production designs.

Well, now the evbppc page says:
"NetBSD/evbppc is intended to be a port of NetBSD to
 various PowerPC-based evaluation boards and appliances."

The "evaluation boards" are often used to develop embedded
systems, so such appliances could also be covered by evb* ports.
Anyway, it's a result of some compromise with consistency
and complexity/redundancy, IMHO.

> > For the kernel part, MD directly should have only MD stuff and
> > all code which can be shared among all mips ports should be in
> > arch/mips. That's all, I think.
> >   
> the problem is that we have e.g. bus_space and pci_machdep and such that
> *could* pretty much be shared (esp. the header files) but instead of
> having a common set, each port seems to have its own.  I can't
> understand why this is.  It seems to me like it increases the risk of
> port-specific regressions and increases maintenance costs.

Well, the bus_space(9) is an "MI API with MD implementation."
We have spent many efforts to define well-designed MI APIs,
but we might have a bit less efforts on MD implementation
because it could be replaced later even if it contained some
awful code, and then its priority might be lower.

Furthermore, IMHO it's not so easy to implement truly generic
bus_space functions for all mips ports. There are too many options
(byteswap, stride, access methods on 8bit ops, etc.) and MD hooks
for such ops might cause some performance penalty.

But if you have a good idea to implement shared code,
there is no reason for me to stop it, of cource. :-)
---
Izumi Tsutsui