Minor reorg...

[M. Warner Losh]

Greetings,

I'd like to propose a minor reorg of the mips tree.  For the moment,
not much will change, since many things already come close to
conforming to this scheme.  I'm presenting it here for interested
parties to comment upon.

First, if you aren't aware of it, I'd like to draw your attention to
the projects/mips svn tree.  In the spirit of openness, we're moving
the main mips development to that tree.  We'll continue with the
perforce tree for a few more weeks, I'm guessing, until we're sure we
have everything moved into the subversion tree.  There's a couple of
things that need to be cleaned up before they can migrate from the
perforce tree, but all the code I'm aware of that falls into that
category should have clean replacements soon.

Next, we have a bit of a hodge-podge of naming schemes in mips right
now:

old		new
------------------------------------
adm5120		<same> or infineon
alchemy		same
atheros		same
idt		same
malta		? malta ?
sentry5		bcm47xx or broadcom

plus the usual compile, conf and mips.  The last three won't change.

As you may have guessed, I'd like to move to having things under mips
be organized by vendor, or chip family.  Currently all the vendors we
have use very closely related families.  Of course, broadcom bought
sibyte a few years ago, so they have multiple families, hence my
wavering between bcm47xx and broadcom for that directory name.  I'm
not sure that we'd benefit much from a adm5120 rename, but I'd like to
be consistent.

Before I rearrange the deck chairs, I thought I'd give people a chance
to comment.

I'd also like to make sure that we have board support separated out
from SoC support, as well as a mechanism in place for doing multiple
boards in one kernel.  I'd also like to abstract out boot loader
support a bit, since that's how the system starts and many boot
loaders are available over a range of SoCs[*].  But those bigger changes
are something that will have to wait for another day.

Should I wait until I have a bigger plan?  Or should I start moving
things around now?

[*] I'm thinking a loader/cfe.c, loader/uboot.c, loader/yamon.c, etc
which will be responsible for determining what board is present, and
jumping that board's init code (likely by calling a probe routine:
haven't worked out the details since I wanted to see how well Sam's
work on ARM in this area played out).

Warner

P.S.  I'm also thinking of revamping the bus_space so it is a table of
pointers, ala ARM, since we're starting to run into mips systems that
would be easier if we had such a thing.