Date: Tue, 20 Jan 2009 22:47:27 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: mips@freebsd.org Subject: Minor reorg... Message-ID: <20090120.224727.1884751430.imp@bsdimp.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090120.224727.1884751430.imp>