[PATCH] Start split out of common open firmware code

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Apr 12 16:36:14 EST 2007


On Wed, 2007-04-11 at 23:25 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Date: Thu, 12 Apr 2007 15:50:20 +1000
> 
> > On Thu, 2007-04-12 at 15:34 +1000, Stephen Rothwell wrote:
> > > This creates kernel/openfw.c (depending on CONFIG_OPENFW) and puts the
> > > first trivially common bits from the prom.c files into it.
> > 
> > Is this the right place ?
> > 
> > I want to split flat DT from live DT in separate files, then we have
> > of_device.c and of_platform.c that will need merging too, and possibly
> > the filesystem... that's a lot to put in kernel/
> 
> We could make drivers/openfw/{device,platform}.c, maybe that would
> work best?

Yeah, we could have something like:

 - base.c (the core stuff that stephen just merged)
 - parse.c (the parsers for irq tree, "reg"/"ranges", ...)
 - device.c
 - platform.c
(there is some work needed for the above to consolidate properly, I
suppose I'm the one who should do it since I'm to blame for most of that
code :-)
 - fs.c

In fact, we could even have trampoline.c for the powerpc prom_init
thingy though I'm not sure there is any interest in having that made
common with sparc, so it might as well stay where it is (in fact, we've
been considering moving it to the zImage wrapper and using the flattened
format to pass the DT along).

In addition, there are things that relate to the flat device-tree which
I don't know how much we want to make generic, both walking it, but also
things to generate one, mostly for use by iSeries and zImage wrappers...

Note that for the filesystem, we really want to stick to our binary
representation while you really want to stick to your text rep (we
decided to disagree iirc :-) I think we could keep a lot in common still
and just have a mount option to indicate how the file content is
exposed.

It's not really 2.6.22 material as far as I'm concerned as I'm pretty
busy with other things, unless of course Stephen feel like doing it
all :-) I'll see what I can do for the next cycle though.

Ben.






More information about the Linuxppc-dev mailing list