The Plan

The Plan

[Paul Mackerras]

(to reduce the arch/ppc/kernel clutter, that is)

This is what I am thinking of; I have implemented it locally here and
I'm doing test compiles with arch/ppc/configs/*.

- arch/ppc/kernel/ppc_asm.h moves to include/asm-ppc, and the contents
  of ppc_asm.tmpl get folded into it, with corresponding changes to
  arch/ppc/*/*.S.

- Files which relate only to one platform, or a small number of
  platforms, move to arch/ppc/platforms.  (There are some minor
  exceptions to this rule which we can discuss if people are
  concerned.)  We end up with:

bash-2.05$ ls kernel/
total 888
   4 Makefile	         8 l2cr.S	       4 ppc8xx_pic.h
  12 align.c	         8 m8260_setup.c       4 ppc_defs.head
   4 bitops.c	        12 m8xx_setup.c       16 ppc_htab.c
  40 btext.c	        24 misc.S	      12 ppc_ksyms.c
   4 checks.c	        12 mk_defs.c	      24 proc_rtas.c
   8 cputable.c         12 mpc10x_common.c    16 process.c
  12 entry.S	         8 oak_setup.c	      56 prom.c
   8 error_log.c         4 oak_setup.h	       8 ptrace.c
   4 error_log.h        24 open_pic.c	      12 qspan_pci.c
   4 find_name.c         8 open_pic_defs.h    28 residual.c
   4 galaxy_pci.c        4 pci-dma.c	       4 semaphore.c
  48 head.S	        36 pci.c	      24 setup.c
  32 head_4xx.S         12 pci_auto.c	      20 signal.c
  24 head_8xx.S         20 ppc-stub.c	      16 smp.c
   8 i8259.c	        20 ppc405_dma.c        4 softemu8xx.c
   4 iSeries_asm.h       8 ppc405_pci.c        8 syscalls.c
  40 iSeries_head.S      8 ppc4xx_pic.c        8 temp.c
  12 iSeries_misc.S      8 ppc4xx_serial.c    16 time.c
   4 iSeries_setup.h    12 ppc4xx_setup.c*    12 todc_time.c
  12 idle.c	         4 ppc8260_pic.c      12 traps.c
   4 indirect_pci.c      4 ppc8260_pic.h
  28 irq.c	         8 ppc8xx_pic.c

bash-2.05$ ls platforms/
total 732
   4 Makefile	         4 iSeries_smp.c       16 pmac_smp.c
   4 adir.h	         8 iSeries_time.c       8 pmac_time.c
  12 adir_pci.c          4 k2.h		       12 powerpmc250.c
   4 adir_pic.c         12 k2_pci.c	        4 pplus.h
   8 adir_setup.c       12 k2_setup.c	       12 pplus_common.c
   8 apus_pci.c          4 lopec_pci.c	        4 prep_nvram.c
   4 apus_pci.h          8 lopec_setup.c       40 prep_pci.c
  28 apus_setup.c        4 mcpn765.h	       24 prep_setup.c
  12 chrp_pci.c          4 mcpn765_pci.c        8 prep_time.c
  16 chrp_setup.c       12 mcpn765_setup.c      8 prpmc750_pci.c
   4 chrp_smp.c          4 menf1.h	        8 prpmc750_setup.c
   8 chrp_time.c         4 menf1_pci.c	        4 prpmc800_pci.c
   4 cpc700.h	         8 menf1_setup.c       12 prpmc800_setup.c
   8 cpc700_pic.c        4 mvme5100_pci.c       4 redwood.c
   4 cpc710.h	         8 mvme5100_setup.c     4 sandpoint.h
   4 cpci405.c	         4 pcore.h	        8 sandpoint_pci.c
   4 ep405.c	         4 pcore_pci.c	       20 sandpoint_setup.c
   4 gemini_pci.c        8 pcore_setup.c        8 sleep.S
   4 gemini_prom.S       4 pmac_backlight.c     4 spruce_pci.c
  16 gemini_setup.c     60 pmac_feature.c       8 spruce_setup.c
   8 harrier.c	        12 pmac_nvram.c         8 walnut.c*
   4 harrier.h	        20 pmac_pci.c	        4 zx4500.h
  32 iSeries_dma.c      16 pmac_pic.c	        4 zx4500_pci.c
   4 iSeries_pic.c       4 pmac_pic.h	       12 zx4500_setup.c
  24 iSeries_setup.c    24 pmac_setup.c

- The appropriate changes to various Makefiles, of course.

We can discuss variations on this theme, for example we could possibly
move platforms/iSeries* to iSeries/, since it already has its own
directory.  As the number of platforms grows, we can consider moving
other groups of platforms into their own directories as well.

Thoughts?  Objections?  Comments?

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Geert Uytterhoeven]

On Wed, 7 Nov 2001, Paul Mackerras wrote:
> - Files which relate only to one platform, or a small number of
>   platforms, move to arch/ppc/platforms.  (There are some minor
>   exceptions to this rule which we can discuss if people are
>   concerned.)  We end up with:

Why not move platform-specific files to arch/ppc/<platform>/ instead?

Your solution reduces the clutter only by a factor of 2, while creating
platform-specific directories reduces it by a factor of n.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Paul Mackerras]

Geert Uytterhoeven writes:

> Why not move platform-specific files to arch/ppc/<platform>/ instead?
>
> Your solution reduces the clutter only by a factor of 2, while creating
> platform-specific directories reduces it by a factor of n.

But adds n extra directories, most of which would only have 2 or 3
files in them, thereby cluttering up arch/ppc.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Frank Rowand]

Paul Mackerras wrote:
>
> Geert Uytterhoeven writes:
>
> > Why not move platform-specific files to arch/ppc/<platform>/ instead?
> >
> > Your solution reduces the clutter only by a factor of 2, while creating
> > platform-specific directories reduces it by a factor of n.
>
> But adds n extra directories, most of which would only have 2 or 3
> files in them, thereby cluttering up arch/ppc.

One advantage of having arch/ppc/<platform>/ is that it allows for
the possibility of arch/ppc/platform/, which is a link to the
specific <platform> which is being built.  This would be similar
to the way that include/asm/ is a link to include/asm-<architecture>/

-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Val Henson]

On Wed, Nov 07, 2001 at 12:47:33PM +0100, Geert Uytterhoeven wrote:
>
> On Wed, 7 Nov 2001, Paul Mackerras wrote:
> > - Files which relate only to one platform, or a small number of
> >   platforms, move to arch/ppc/platforms.  (There are some minor
> >   exceptions to this rule which we can discuss if people are
> >   concerned.)  We end up with:
>
> Why not move platform-specific files to arch/ppc/<platform>/ instead?
>
> Your solution reduces the clutter only by a factor of 2, while creating
> platform-specific directories reduces it by a factor of n.

I agree with Geert.  I don't think that dividing the clutter into two
directories instead of one really improves matters.  Each directory is
still monstrously huge and the division is non-obvious.
arch/ppc/masochist would be easier to understand. :)

What is the problem we're trying to solve here?

-VAL

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Mark A. Greer]

Val Henson wrote:

> I agree with Geert.  I don't think that dividing the clutter into two
> directories instead of one really improves matters.  Each directory is
> still monstrously huge and the division is non-obvious.
> arch/ppc/masochist would be easier to understand. :)

Yeah but if you do it the other way, you end up with a directory with a
clutter of subdirs--exchanged one clutter for another.

> What is the problem we're trying to solve here?

Hmmm, clutter I suppose but to be honest I don't have a problem with the way
it is now...

Mark


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Mark A. Greer]

"Mark A. Greer" wrote:

> Hmmm, clutter I suppose but to be honest I don't have a problem with the way
> it is now...

That is as long as everyone uses descriptive file names.

Now that I think about it a little more, I do like the platforms dir
idea...separates board-specific code from more generic infracture code (e.g.,
bridge code, todc, head.S)

Mark


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Matt Porter]

On Wed, Nov 07, 2001 at 10:35:07PM +1100, Paul Mackerras wrote:
>
> (to reduce the arch/ppc/kernel clutter, that is)

<snip>

> We can discuss variations on this theme, for example we could possibly
> move platforms/iSeries* to iSeries/, since it already has its own
> directory.  As the number of platforms grows, we can consider moving
> other groups of platforms into their own directories as well.

Sounds great to me.  I'd like to fold a number of embedded 7xx/74xx
system files into directories by their manufacturer names.

arch/ppc/kernel/platforms/Motorola/
					sandpoint_*
					mvme5100_*
					mcp765_*
					etc.
arch/ppc/kernel/platforms/Force/
					pcore_*
					powerpmc_*
					etc.

arch/ppc/kernel/platforms/xyz/
...

The next step (since we've all been working away at abstracting
our common interfaces) is to collapse the *_[setup|pci].c files
in a single file to further reduce clutter on those systems for
which it makes practical sense.  Again, that's most of our
embedded 7xx/74xx/8240 ports.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Mark A. Greer]

Paul Mackerras wrote:

> This is what I am thinking of; I have implemented it locally here and
> I'm doing test compiles with arch/ppc/configs/*.
>
> - arch/ppc/kernel/ppc_asm.h moves to include/asm-ppc, and the contents
>   of ppc_asm.tmpl get folded into it, with corresponding changes to
>   arch/ppc/*/*.S.
>
> - Files which relate only to one platform, or a small number of
>   platforms, move to arch/ppc/platforms.  (There are some minor
>   exceptions to this rule which we can discuss if people are
>   concerned.)  We end up with:

I like this too.  Seems like a good compromise between one dir with a
bunch of files and a bunch of dirs each with a couple files.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Mark A. Greer]

Paul,

I would move harrier.c and pplus_common.c to the "kernel" dir since they
are both bridge related files (kinda like the mpc10x_common.c file).

Mark


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Paul Mackerras]

Mark A. Greer writes:

> I would move harrier.c and pplus_common.c to the "kernel" dir since they
> are both bridge related files (kinda like the mpc10x_common.c file).

I wondered about pplus_common.c, actually.  Are pplus_common.c and
harrier.c likely to be used by more than one or two platforms in the
future?  If we leave them in kernel then we need to move the
corresponding header files to include/asm-ppc.

BTW, I would love to find a way to move all the platform-specific
files (mvme5100.h, for instance) from include/asm-ppc to
arch/ppc/platforms too.  The obstacle at the moment is the serial
stuff.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Mark A. Greer]

Paul Mackerras wrote:

> Mark A. Greer writes:
>
> > I would move harrier.c and pplus_common.c to the "kernel" dir since they
> > are both bridge related files (kinda like the mpc10x_common.c file).
>
> I wondered about pplus_common.c, actually.  Are pplus_common.c and
> harrier.c likely to be used by more than one or two platforms in the
> future?

Depends what  you mean by "platform".

Basically, most of the older MCG boards will use pplus_common.c (supports
falcon/raven and hawk); most of the newer ones will use the harrier.  It
depends on whether the MCG boards are supported by one or two "board ports"
or if each board has its own "board port".  Lately, we've been separating
them out because there have been more significant differences between the
various boards and having things like residual data are not assured anymore
(or residual data that's close to correct).

Any comments Matt?

> If we leave them in kernel then we need to move the
> corresponding header files to include/asm-ppc.

> BTW, I would love to find a way to move all the platform-specific
> files (mvme5100.h, for instance) from include/asm-ppc to
> arch/ppc/platforms too.  The obstacle at the moment is the serial
> stuff.

Sounds like the right place to me too.

Mark


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Mark A. Greer]

ok, last one:

My guess is to also move cpc700*, cpc710*, sleep.S (in addition to pplus*
and harrier*).

A separate question...isn't prep_time.c obsolete with todc_time.c?  What
about chrp_time.c and others?

YES, I need to make it mp-safe (as Tom requested).  I will do that soon.

Mark


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Tom Rini]

On Wed, Nov 07, 2001 at 05:48:14PM -0700, Mark A. Greer wrote:

> My guess is to also move cpc700*, cpc710*, sleep.S (in addition to pplus*
> and harrier*).
>
> A separate question...isn't prep_time.c obsolete with todc_time.c?

Almost.  I had this working for my PowerStack months ago I think, but I
had the bits wrong for IBM PRePs.  I'll play with again RSN and
hopefully kill prep_time.c

> What
> about chrp_time.c and others?

No, because it's all OF-based stuff.

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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Chris Emerson]

On Wed, Nov 07, 2001 at 10:35:07PM +1100, Paul Mackerras wrote:
> (to reduce the arch/ppc/kernel clutter, that is)
>
> This is what I am thinking of; I have implemented it locally here and
> I'm doing test compiles with arch/ppc/configs/*.
>
> - arch/ppc/kernel/ppc_asm.h moves to include/asm-ppc, and the contents
>   of ppc_asm.tmpl get folded into it, with corresponding changes to
>   arch/ppc/*/*.S.

This sounds like a good thing for the user-mode port, which tries to use
a couple of the assembler files from arch/ppc.  There's some hideous symlink
hackery going on to get them to work at the moment.  If it's all just in
include/asm-ppc, that should be much nicer.

Cheers,

Chris

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: The Plan

[Geert Uytterhoeven]

On Thu, 8 Nov 2001, Chris Emerson wrote:
> On Wed, Nov 07, 2001 at 10:35:07PM +1100, Paul Mackerras wrote:
> > (to reduce the arch/ppc/kernel clutter, that is)
> >
> > This is what I am thinking of; I have implemented it locally here and
> > I'm doing test compiles with arch/ppc/configs/*.
> >
> > - arch/ppc/kernel/ppc_asm.h moves to include/asm-ppc, and the contents
> >   of ppc_asm.tmpl get folded into it, with corresponding changes to
> >   arch/ppc/*/*.S.
>
> This sounds like a good thing for the user-mode port, which tries to use
> a couple of the assembler files from arch/ppc.  There's some hideous symlink
> hackery going on to get them to work at the moment.  If it's all just in
> include/asm-ppc, that should be much nicer.

Both MIPS and ARM have board-specific directories in include/asm-*/ and
arch/*/.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

The Plan

[David Miller]

Everything in net-2.6 right now, as well as the final fix
we come up with for the GRO issue will get sucked into
net-next-2.6 as well as queued up for -stable.

Everything in patchwork right now will either be merged
into net-next-2.6 or tossed.

I'll likely send my pull request to Linus tomorrow.

Once that goes in, both net-2.6 and net-next-2.6 will become
fresh clones of Linus's tree.

RE: The Plan

[Ramkrishna Vepa]

Dave,

We were planning to resubmit the new vxge driver later today to net-2.6.
Can we proceed with this plan of action?

Thanks,
Ram

> -----Original Message-----
> From: netdev-owner@vger.kernel.org
[mailto:netdev-owner@vger.kernel.org]
> On Behalf Of David Miller
> Sent: Tuesday, March 24, 2009 3:35 PM
> To: netdev@vger.kernel.org
> Subject: The Plan
> 
> 
> Everything in net-2.6 right now, as well as the final fix
> we come up with for the GRO issue will get sucked into
> net-next-2.6 as well as queued up for -stable.
> 
> Everything in patchwork right now will either be merged
> into net-next-2.6 or tossed.
> 
> I'll likely send my pull request to Linus tomorrow.
> 
> Once that goes in, both net-2.6 and net-next-2.6 will become
> fresh clones of Linus's tree.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: The Plan

[David Miller]

From: "Ramkrishna Vepa" <Ramkrishna.Vepa@neterion.com>
Date: Tue, 24 Mar 2009 18:43:15 -0400

> We were planning to resubmit the new vxge driver later today to net-2.6.
> Can we proceed with this plan of action?

It's a new driver, so sure.

Re: The Plan

[Vlad Yasevich]

David Miller wrote:
> Everything in net-2.6 right now, as well as the final fix
> we come up with for the GRO issue will get sucked into
> net-next-2.6 as well as queued up for -stable.
> 
> Everything in patchwork right now will either be merged
> into net-next-2.6 or tossed.
> 

Hi David

Can you give any indication which way you are leaning on the IPv6 binding
patches?

I have some updates and can resubmit if you are planning on taking them.

Thanks
-vlad

Re: The Plan

[David Miller]

From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Tue, 24 Mar 2009 22:03:28 -0400

> Can you give any indication which way you are leaning on the IPv6
> binding patches?

I'll probably apply them.

> I have some updates and can resubmit if you are planning on taking
> them.

Please send them sooner rather than later.