Gereald,
The following is copied from one of my previous posts in linux-mips mailing
list. I think this is a reasonable idea.
BTW, do_initcalls() scheme is the same thing as Ralf is referring to as ELF
section.
Jun
.....
I talked about machine detection a while back. My idea is following:
0. all machines that are *configured* into the image will supply <my>_detect()
and <my>_setup() functions.
1. at MIPS start up, we loop through all <my>_detect(), which returns three
values, a) run-time detection negative, b) run-time detection positive, and c)
no run-time detection code, but I return positive because I am configured in.
2. the startup code resolves conflicts (which sometimes may panic); and decide
on one machine.
3. then the startup code calls the right <my>_setup() code which will set up
the mach_type and other stuff.
BTW, a side benenfit of doing this is that we can remove all the machine
specific code in common files such as bootinfo.h, setup.c, etc, which are
getting harder and harder to maintain as we are adding more and more embedded
boards to the tree.
If we push it to an extreme by using mechnism like do_initcalls(), we can
achieve zero common source file modification when adding a new a machine.
This will greatly facilitate embedded development as it allows more parallel
development and allow people to maintain their own board code much easier
before the code is submitted to the tree.
Jun
Ralf Baechle wrote:
>
> On Wed, Oct 03, 2001 at 02:11:26PM -0500, Gerald Champagne wrote:
>
> > For each configuration, only one case is compiled in. Wouldn't it
> > be simpler to just give the board-specific setup function a common name
> > and consider it part of the board-specific api like all the other
> > board-specific functions. Can this be changed to just this:
> >
> > -----------------
> > void __init setup_arch(char **cmdline_p)
> > {
> > void foo_setup(void);
> >
> > ...
> >
> > foo_setup(); /* someone pick a name for this */
> > ...
> > -----------------
> >
> > I'm trying to document an api for supporting an arbitrary board, and little
> > things like this make it more difficult to define something along the lines
> > of a bsp interface. Any suggestions? Any objections?
>
> We used to allow support for multiple boards in one kernel binary though
> that usually doesn't work for MIPS due to the large number of very different
> systems. People have asked to resurrect this option, so I'd like to go
> for an option that only removes all those awful #ifdefs. Something based
> on ELF sections looks like a way to do this.
>
> Ralf
