RFC: proposed arch/powerpc directory structure

RFC: proposed arch/powerpc directory structure

[Becky Bruce]

All,

In the name of moving the much-anticipated 32/64 ppc merge along, Kumar 
Gala, Jon Loeliger, and myself have worked out an initial proposal for 
the directory structure of the new merged arch/powerpc.  Listed below 
are the proposed directories, along with a description of the logical 
contents, as well as a description of which existing files will be 
moved into these directories.

There was some discussion on the list recently about whether or not it 
might be better to change things around to be laid out more along the 
lines of functionality with, say, all pci-related code in one place.  
We've stuck with a more traditional model in this proposal, although 
the topic is certainly still up for discussion.

This is just a first pass at a structure - we're really looking for 
input from this list on the best way to proceed, and that discussion 
needs to start somewhere.  BTW, this proposal preempts the previous 
64-bit directory structure reorg proposal that I sent to this list a 
couple of months ago.

So here it is:

include/powerpc/

arch/powerpc/
	configs/
		- Kconfig defaults per buildable board.

	boot/
		- Pre-kernel execution shims and pre-passes.
		- Convert firmware reprensentations (bi_recs, OF Dev-Trees,
		 bootx,bd_t) to flat-dev-trees.
		- Includes merged files from arch/ppc*/boot/ trees, plus
		prom_init.c from arch/ppc64/kernel.

	kernel/
		- CPU-centric core code and generic PPC-specific kernel
		- Main entry point supports r5=0, r3 = flat-dev-tree, etc.
		- Includes all cpu core-specific code, kernel initialization code,
		and other generic kernel foo like smp, ptrace, syscalls, etc from
		arch/ppc*/kernel.  Files not belonging to one of these categories
		will be moved to other directories.


	platforms/
		- platform-specific code laid out in the following directories:
		pSeries/
		iSeries/
		pmac/  (both 32 and 64-bit)
		classic32/  (platforms containing 6xx/7xx/74xx/8240/8241/8245)
		classic64/  (Maple?)
		83xx/ (may collapse into classic 32 at some point)
		86xx/ (may collapse into classic 32 at some point)
		pq2/ (may collapse into classic 32 at some point)
		52xx/ (may collapse into classic 32 at some point)
		85xx/
		4xx/
		8xx/
		- Includes all code from arch/ppc/platforms, all code from
		arch/ppc64/kernel that is specific to a given platform (where a
		platform is a whole computer system or board)
	
		NOTE: there would be no .[chS] files directly under platforms -
		all live in subdirs.

	mm/
		- Memory management, slabs, tlbs, etc.
		- Unify LMB and mem_pieces for early boot memory.
		- Includes all code from arch/ppc*/mm

	sysdev/
		- System Device support and Kitchen Sink
		- Includes all code currently in arch/ppc/syslib, irq and pci code
		that currently lives in arch/ppc/kernel, and all code from
		arch/ppc64/kernel that is generic system code, including pci,
		irq, interrupt control, bridges, rtas(?)

	lib/
		- Library code
		- Includes all code from arch/ppc*/lib

	math-emu/
		- Math Emulation for FPU-less ppc32s.
		- this is 32-bit only, so this directory would just move from
		arch/ppc to arch/powerpc

	oprofile/
		- Support for oprofile.
		- Includes all code from arch/ppc*/oprofile

	xmon/
		- Support for xmon.
		- Includes all code from arch/ppc*xmon


Cheers,
-Becky

Re: RFC: proposed arch/powerpc directory structure

[Dan Malek]

On Aug 10, 2005, at 12:45 PM, Becky Bruce wrote:

> ....  Listed below are the proposed directories, along with a 
> description of the logical contents, as well as a description of which 
> existing files will be moved into these directories.

I think this is fine, but I'd like to make a suggestion about the file 
names themselves.
Since we have platform directories for a specific processor type or 
core, can we
change the file names a little?  For example, if I'm in the 
platforms/82xx directory,
I don't need to prepend every file with mpc82xx_ or ppc82xx- or 
whatever.  We
know that's what it is, let's try to use the file names to be more 
descriptive of what's
inside of them.  Regardless of the build or management tools we use, I 
still find it
nice to keep a concise file name that is still descriptive, and take 
advantage of
the directory structure names to assist with this.

Thanks.


	-- Dan

Re: RFC: proposed arch/powerpc directory structure

[John W. Linville]

On Wed, Aug 10, 2005 at 01:01:34PM -0400, Dan Malek wrote:

> inside of them.  Regardless of the build or management tools we use, I 
> still find it
> nice to keep a concise file name that is still descriptive, and take 
> advantage of
> the directory structure names to assist with this.

I'll second that, fwiw...

John
-- 
John W. Linville
linville@tuxdriver.com

Re: RFC: proposed arch/powerpc directory structure

[Stephen Rothwell]

On Wed, 10 Aug 2005 11:45:10 -0500 Becky Bruce
<becky.bruce@freescale.com> wrote:
>
> 	platforms/
> 		- platform-specific code laid out in the following
> directories: pSeries/
> 		iSeries/

Please, lets get rid of the StudLy CaPs :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: RFC: proposed arch/powerpc directory structure

[Olof Johansson]

On Thu, Aug 11, 2005 at 10:09:11AM +1000, Stephen Rothwell wrote:
> On Wed, 10 Aug 2005 11:45:10 -0500 Becky Bruce
> <becky.bruce@freescale.com> wrote:
> >
> > 	platforms/
> > 		- platform-specific code laid out in the following
> > directories: pSeries/
> > 		iSeries/
> 
> Please, lets get rid of the StudLy CaPs :-)

Actually, might be a good time to start calling pSeries something else
too, since it's no longer just pSeries that uses the platform.

papr? rpa?


-Olof

Re: RFC: proposed arch/powerpc directory structure

[Tom Rini]

On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:

[snip]
> 	platforms/
> 		- platform-specific code laid out in the following 
> 		directories:
> 		pSeries/
> 		iSeries/
> 		pmac/  (both 32 and 64-bit)
> 		classic32/  (platforms containing 
> 		6xx/7xx/74xx/8240/8241/8245)
> 		classic64/  (Maple?)

I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
OpenFirmware-containing ppc64 box (like Maple) ?  How about just 9xx/
for all of the ppc64's that have a 9xx in them (Maple), that aren't pmac
(which is a class of its own).

> 		83xx/ (may collapse into classic 32 at some point)
> 		86xx/ (may collapse into classic 32 at some point)
> 		pq2/ (may collapse into classic 32 at some point)

PQ2 is the marketing name for 82xx, lets just call it 82xx.

I don't like the idea of sticking subdirs in classic32/ either, but also
can't think of a better name for the catchall of 7xx and 74xx boards.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: RFC: proposed arch/powerpc directory structure

[Kumar Gala]

On Aug 11, 2005, at 2:59 PM, Tom Rini wrote:

> On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
>
> [snip]
>
>>     platforms/
>>         - platform-specific code laid out in the following
>>         directories:
>>         pSeries/
>>         iSeries/
>>         pmac/  (both 32 and 64-bit)
>>         classic32/  (platforms containing
>>         6xx/7xx/74xx/8240/8241/8245)
>>         classic64/  (Maple?)
>>
>
> I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> OpenFirmware-containing ppc64 box (like Maple) ?  How about just 9xx/
> for all of the ppc64's that have a 9xx in them (Maple), that aren't  
> pmac
> (which is a class of its own).
>
>
>>         83xx/ (may collapse into classic 32 at some point)
>>         86xx/ (may collapse into classic 32 at some point)
>>         pq2/ (may collapse into classic 32 at some point)
>>
>
> PQ2 is the marketing name for 82xx, lets just call it 82xx.

The problem is that PQ2 describes a subset of 82xx (it nots  
8240/8241/8245).

> I don't like the idea of sticking subdirs in classic32/ either, but  
> also
> can't think of a better name for the catchall of 7xx and 74xx boards.

I dont think we where planning on subdirs in classic32.

- kumar

Re: RFC: proposed arch/powerpc directory structure

[Tom Rini]

On Thu, Aug 11, 2005 at 03:13:30PM -0500, Kumar Gala wrote:
> 
> On Aug 11, 2005, at 2:59 PM, Tom Rini wrote:
> 
> >On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
> >
> >[snip]
[snip]
> >>        83xx/ (may collapse into classic 32 at some point)
> >>        86xx/ (may collapse into classic 32 at some point)
> >>        pq2/ (may collapse into classic 32 at some point)
> >>
> >
> >PQ2 is the marketing name for 82xx, lets just call it 82xx.
> 
> The problem is that PQ2 describes a subset of 82xx (it nots  
> 8240/8241/8245).

All the more reason imho to stick all 82xx stuff under '82xx', rather
than classic32 or 'pq2'.

> >I don't like the idea of sticking subdirs in classic32/ either, but  
> >also
> >can't think of a better name for the catchall of 7xx and 74xx boards.
> 
> I dont think we where planning on subdirs in classic32.

I took "may collapse into classic 32 at some point" to mean "move into
classic32/ at some point", for some reason.  collapsing the content into
classic32/ will bring us back to the bad-old-days of everything in
platforms/ (or kernel/).

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: RFC: proposed arch/powerpc directory structure

[Becky Bruce]

>
>>> I don't like the idea of sticking subdirs in classic32/ either, but
>>> also
>>> can't think of a better name for the catchall of 7xx and 74xx boards.
>>
>> I dont think we where planning on subdirs in classic32.
>
> I took "may collapse into classic 32 at some point" to mean "move into
> classic32/ at some point", for some reason.  collapsing the content 
> into
> classic32/ will bring us back to the bad-old-days of everything in
> platforms/ (or kernel/).

My apologies - this wasn't at all clear in the proposal.  The plan at 
present is to not have subdirs under classic32.  By "collapsing into 
classic32", I meant a move to a more common code base, not a wholescale 
copy of the existing files into classic32.

Cheers,
-B

Re: RFC: proposed arch/powerpc directory structure

[Kumar Gala]

On Aug 11, 2005, at 3:18 PM, Tom Rini wrote:

> On Thu, Aug 11, 2005 at 03:13:30PM -0500, Kumar Gala wrote:
>
>>
>> On Aug 11, 2005, at 2:59 PM, Tom Rini wrote:
>>
>>
>>> On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
>>>
>>> [snip]
>>>
> [snip]
>
>>>>        83xx/ (may collapse into classic 32 at some point)
>>>>        86xx/ (may collapse into classic 32 at some point)
>>>>        pq2/ (may collapse into classic 32 at some point)
>>>>
>>>>
>>>
>>> PQ2 is the marketing name for 82xx, lets just call it 82xx.
>>>
>>
>> The problem is that PQ2 describes a subset of 82xx (it nots
>> 8240/8241/8245).
>>
>
> All the more reason imho to stick all 82xx stuff under '82xx', rather
> than classic32 or 'pq2'.

I think this causes confusion.  the reason we suggested pq2 and  
classic32 was to handle things like sandpoint.  Sandpoint would live  
in classic32.  The confusion partial comes from the fact that we can  
run 8240/1/5 on a Sandpoint.  The thinking was everything that was  
6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +  
10x bridge would be classic32.

If it was 82xx w/o a CPM it went into classic32.  If it was a 82xx w/ 
CPM it went into pq2.  The idea being that we might be able to build  
kernels in either directory that supported a large number of boards  
with one image.

Anyways, that was the thought process to try and keep things sane.   
(Which it may not ;)

- kumar

Re: RFC: proposed arch/powerpc directory structure

[Tom Rini]

On Thu, Aug 11, 2005 at 06:07:03PM -0500, Kumar Gala wrote:
[snip]
> I think this causes confusion.  the reason we suggested pq2 and  
> classic32 was to handle things like sandpoint.  Sandpoint would live  
> in classic32.  The confusion partial comes from the fact that we can  
> run 8240/1/5 on a Sandpoint.  The thinking was everything that was  
> 6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +  
> 10x bridge would be classic32.

Thanks for the explanation.  But I think this is overkill for the
sandpoint or true like a sandpoint (Zynx something, Willow, neither of
which are in the kernel tree).  I think we can field the "I wanna hack
on my Sandpoint/8240, but don't see the code under 82xx/!" question. :)

> If it was 82xx w/o a CPM it went into classic32.  If it was a 82xx w/ 
> CPM it went into pq2.  The idea being that we might be able to build  
> kernels in either directory that supported a large number of boards  
> with one image.

We can certainly investigate just how many distinct boards can be
supported with one image when infos are passed dynamically.  If we can
simplify things enough, maybe we can break the rule of no .[ch] files in
arch/powerpc/platforms since it'll just be 82xx.[ch], 83xx.[ch] and so
on, execept for that damn pmac. ;)

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: RFC: proposed arch/powerpc directory structure

[Kumar Gala]

On Aug 11, 2005, at 6:19 PM, Tom Rini wrote:

> On Thu, Aug 11, 2005 at 06:07:03PM -0500, Kumar Gala wrote:
> [snip]
>
>> I think this causes confusion.  the reason we suggested pq2 and
>> classic32 was to handle things like sandpoint.  Sandpoint would live
>> in classic32.  The confusion partial comes from the fact that we can
>> run 8240/1/5 on a Sandpoint.  The thinking was everything that was
>> 6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +
>> 10x bridge would be classic32.
>>
>
> Thanks for the explanation.  But I think this is overkill for the
> sandpoint or true like a sandpoint (Zynx something, Willow, neither of
> which are in the kernel tree).  I think we can field the "I wanna hack
> on my Sandpoint/8240, but don't see the code under 82xx/!"  
> question. :)

So where do you suggest Sandpoint goes in this directory structure?

- kumar

Re: RFC: proposed arch/powerpc directory structure

[Tom Rini]

On Thu, Aug 11, 2005 at 09:34:57PM -0500, Kumar Gala wrote:
> 
> On Aug 11, 2005, at 6:19 PM, Tom Rini wrote:
> 
> >On Thu, Aug 11, 2005 at 06:07:03PM -0500, Kumar Gala wrote:
> >[snip]
> >
> >>I think this causes confusion.  the reason we suggested pq2 and
> >>classic32 was to handle things like sandpoint.  Sandpoint would live
> >>in classic32.  The confusion partial comes from the fact that we can
> >>run 8240/1/5 on a Sandpoint.  The thinking was everything that was
> >>6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +
> >>10x bridge would be classic32.
> >>
> >
> >Thanks for the explanation.  But I think this is overkill for the
> >sandpoint or true like a sandpoint (Zynx something, Willow, neither of
> >which are in the kernel tree).  I think we can field the "I wanna hack
> >on my Sandpoint/8240, but don't see the code under 82xx/!"  
> >question. :)
> 
> So where do you suggest Sandpoint goes in this directory structure?

classic32/

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: RFC: proposed arch/powerpc directory structure

[Dan Malek]

On Aug 11, 2005, at 7:07 PM, Kumar Gala wrote:

> ......  The idea being that we might be able to build kernels in 
> either directory that supported a large number of boards with one 
> image.

Please don't go there :-)  I'm having enough trouble meeting reasonable
performance goals in 2.6 on embedded systems that I don't need the 
overhead
of code bloat or extra cycles to determine what board I'm on.  Contrary 
to
the belief of developers, products don't have the resource wealth we see
on these evaluation and ODM boards.  Embedded products still require
we build kernels (and everything else) as concisely and efficient as 
possible.

Thanks.

	-- Dan

Re: RFC: proposed arch/powerpc directory structure

[Josh Boyer]

On Thu, 2005-08-11 at 12:59 -0700, Tom Rini wrote:
> On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
> 
> [snip]
> > 	platforms/
> > 		- platform-specific code laid out in the following 
> > 		directories:
> > 		pSeries/
> > 		iSeries/
> > 		pmac/  (both 32 and 64-bit)
> > 		classic32/  (platforms containing 
> > 		6xx/7xx/74xx/8240/8241/8245)
> > 		classic64/  (Maple?)
> 
> I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> OpenFirmware-containing ppc64 box (like Maple) ?  How about just 9xx/
> for all of the ppc64's that have a 9xx in them (Maple), that aren't pmac
> (which is a class of its own).

I myself am also pretty ppc64 ignorant, but I do know that not all
pSeries are 9xx based.  There are POWER 4 and POWER 5 pSeries boxes too.

josh

Re: RFC: proposed arch/powerpc directory structure

[Paul Mackerras]

Tom Rini writes:

> I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> OpenFirmware-containing ppc64 box (like Maple) ?  How about just 9xx/

Ummm, no, not exactly.  The distinctive thing about pSeries is the
hypervisor interfaces.  And in fact most pSeries boxes aren't
970-based, rather POWER4/4+/5.  If you want to generalize, we could
call the directory "papr" (for Power Architecture Platform
Requirements, the name of the document that describes the pSeries
platforms) rather than pSeries, but I suspect that would just confuse
people. :)

Paul.

Re: RFC: proposed arch/powerpc directory structure

[Tom Rini]

On Fri, Aug 12, 2005 at 01:49:22PM +1000, Paul Mackerras wrote:
> Tom Rini writes:
> 
> > I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> > OpenFirmware-containing ppc64 box (like Maple) ?  How about just 9xx/
> 
> Ummm, no, not exactly.  The distinctive thing about pSeries is the
> hypervisor interfaces.  And in fact most pSeries boxes aren't
> 970-based, rather POWER4/4+/5.  If you want to generalize, we could
> call the directory "papr" (for Power Architecture Platform
> Requirements, the name of the document that describes the pSeries
> platforms) rather than pSeries, but I suspect that would just confuse
> people. :)

Ok.  How about 9xx/ instead of classic64 ?

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: RFC: proposed arch/powerpc directory structure

[Segher Boessenkool]

> Ok.  How about 9xx/ instead of classic64 ?

That would be tons better, as there doesn't exist anything
called "classic64"...


Segher

Re: RFC: proposed arch/powerpc directory structure

[Olaf Hering]

 On Wed, Aug 10, Becky Bruce wrote:

> 	boot/
> 		- Pre-kernel execution shims and pre-passes.
> 		- Convert firmware reprensentations (bi_recs, OF Dev-Trees,
> 		 bootx,bd_t) to flat-dev-trees.
> 		- Includes merged files from arch/ppc*/boot/ trees, plus
> 		prom_init.c from arch/ppc64/kernel.

This should live outside the kernel source, in a $mkzimage project.