PATCH powerpc: Merge asm-ppc*/sections.h

Here is a patch to merge asm-ppc*/sections.h.

If anyone knows if we can do better here,
please feel free to abuse, er, let me know!

Signed-off-by: Jon Loeliger <redacted>
---

diff --git a/include/asm-powerpc/sections.h b/include/asm-powerpc/sections.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/sections.h

@@ -0,0 +1,62 @@
+#ifndef _ASM_POWERPC_SECTIONS_H
+#define _ASM_POWERPC_SECTIONS_H
+
+#ifdef __KERNEL__
+
+#include <asm-generic/sections.h>
+
+#ifdef __powerpc64__
+
+#define __pmac
+#define __pmacdata
+
+#define __prep
+#define __prepdata
+
+#define __chrp
+#define __chrpdata
+
+#define __openfirmware
+#define __openfirmwaredata
+
+extern char _end[];
+
+static inline int in_kernel_text(unsigned long addr)
+{
+	if (addr >= (unsigned long)_stext && addr < (unsigned long)__init_end)
+		return 1;
+
+	return 0;
+}
+
+#else	/* __powerpc64__ */
+
+#define __pmac __attribute__ ((__section__ (".pmac.text")))
+#define __pmacdata __attribute__ ((__section__ (".pmac.data")))
+#define __pmacfunc(__argpmac) \
+	__argpmac __pmac; \
+	__argpmac
+	
+#define __prep __attribute__ ((__section__ (".prep.text")))
+#define __prepdata __attribute__ ((__section__ (".prep.data")))
+#define __prepfunc(__argprep) \
+	__argprep __prep; \
+	__argprep
+
+#define __chrp __attribute__ ((__section__ (".chrp.text")))
+#define __chrpdata __attribute__ ((__section__ (".chrp.data")))
+#define __chrpfunc(__argchrp) \
+	__argchrp __chrp; \
+	__argchrp
+
+/* this is actually just common chrp/pmac code, not OF code -- Cort */
+#define __openfirmware __attribute__ ((__section__ (".openfirmware.text")))
+#define __openfirmwaredata __attribute__ ((__section__ (".openfirmware.data")))
+#define __openfirmwarefunc(__argopenfirmware) \
+	__argopenfirmware __openfirmware; \
+	__argopenfirmware
+
+#endif	/* __powerpc64__ */
+	
+#endif	/* __KERNEL__ */
+#endif	/* _ASM_POWERPC_SECTIONS_H */

diff --git a/include/asm-ppc/sections.h b/include/asm-ppc/sections.h
deleted file mode 100644
--- a/include/asm-ppc/sections.h
+++ /dev/null

@@ -1,33 +0,0 @@
-#ifdef __KERNEL__
-#ifndef _PPC_SECTIONS_H
-#define _PPC_SECTIONS_H
-
-#include <asm-generic/sections.h>
-
-#define __pmac __attribute__ ((__section__ (".pmac.text")))
-#define __pmacdata __attribute__ ((__section__ (".pmac.data")))
-#define __pmacfunc(__argpmac) \
-	__argpmac __pmac; \
-	__argpmac
-	
-#define __prep __attribute__ ((__section__ (".prep.text")))
-#define __prepdata __attribute__ ((__section__ (".prep.data")))
-#define __prepfunc(__argprep) \
-	__argprep __prep; \
-	__argprep
-
-#define __chrp __attribute__ ((__section__ (".chrp.text")))
-#define __chrpdata __attribute__ ((__section__ (".chrp.data")))
-#define __chrpfunc(__argchrp) \
-	__argchrp __chrp; \
-	__argchrp
-
-/* this is actually just common chrp/pmac code, not OF code -- Cort */
-#define __openfirmware __attribute__ ((__section__ (".openfirmware.text")))
-#define __openfirmwaredata __attribute__ ((__section__ (".openfirmware.data")))
-#define __openfirmwarefunc(__argopenfirmware) \
-	__argopenfirmware __openfirmware; \
-	__argopenfirmware
-	
-#endif /* _PPC_SECTIONS_H */
-#endif /* __KERNEL__ */

diff --git a/include/asm-ppc64/sections.h b/include/asm-ppc64/sections.h
deleted file mode 100644
--- a/include/asm-ppc64/sections.h
+++ /dev/null

@@ -1,29 +0,0 @@
-#ifndef _PPC64_SECTIONS_H
-#define _PPC64_SECTIONS_H
-
-extern char _end[];
-
-#include <asm-generic/sections.h>
-
-#define __pmac
-#define __pmacdata
-
-#define __prep
-#define __prepdata
-
-#define __chrp
-#define __chrpdata
-
-#define __openfirmware
-#define __openfirmwaredata
-
-
-static inline int in_kernel_text(unsigned long addr)
-{
-	if (addr >= (unsigned long)_stext && addr < (unsigned long)__init_end)
-		return 1;
-
-	return 0;
-}
-
-#endif

On Dinsdag 13 September 2005 22:43, Jon Loeliger wrote:

Here is a patch to merge asm-ppc*/sections.h.

If anyone knows if we can do better here,
please feel free to abuse, er, let me know!

Ok, I don't like this patch. IMHO for the architecture merge, we should
have a common implementation of this, either always using per-platform
sections or never using them, meaning that we get rid of this file.

At the very least, the __*func() macros should go away, they are completely
bogus.

Using the sections in arch/powerpc has the obvious advantage that it
reduces the size of the running kernel, but also has a certain amount
of bug-potential or at least makes the code slightly more ugly.
It is also easier to remove the feature in ppc than adding it in ppc64.

The users of the ppc64 function in_kernel_text() can probably be converted
to the generic is_kernel_text() function.

	Arnd <><

On Tue, 2005-09-13 at 21:35, Arnd Bergmann wrote:

On Dinsdag 13 September 2005 22:43, Jon Loeliger wrote:

quoted

Here is a patch to merge asm-ppc*/sections.h.

If anyone knows if we can do better here,
please feel free to abuse, er, let me know!

Ok, I don't like this patch. 

You will be pleased to know, then, that Becky and I both
didn't like this patch either. :-)

IMHO for the architecture merge, we should
have a common implementation of this, either always using per-platform
sections or never using them, meaning that we get rid of this file.

Yeah.

At the very least, the __*func() macros should go away, they are completely
bogus.

I'll work on eliminating those (at least) and submitting a
cleanup patch for that as needed.

Using the sections in arch/powerpc has the obvious advantage that it
reduces the size of the running kernel, but also has a certain amount
of bug-potential or at least makes the code slightly more ugly.
It is also easier to remove the feature in ppc than adding it in ppc64.

In the Grand Scheme of Things, removing things and making them
simpler seems a lofty goal. :-)   Anyone know of any pitfalls that
await me if I try to remove these sections, a la pmac and friends?
And I assume that the obvious mappings can take place (ie, that
"pmac.text" can just be placed in regular .text, etc), right?

The users of the ppc64 function in_kernel_text() can probably be converted
to the generic is_kernel_text() function.

I'll peer into that a bit too.

	Arnd <><

Thanks!
jdl

Jon Loeliger writes:

In the Grand Scheme of Things, removing things and making them
simpler seems a lofty goal. :-)   Anyone know of any pitfalls that
await me if I try to remove these sections, a la pmac and friends?

You'll probably get most objection from the PReP users, for whom
getting back a few hundred kB is a big deal.  (Maybe we should just
buy both of them a G5 or something. 8-)

And I assume that the obvious mappings can take place (ie, that
"pmac.text" can just be placed in regular .text, etc), right?

Yes.

Paul.

On Thu, 2005-09-15 at 06:09, Paul Mackerras wrote:

Jon Loeliger writes:

quoted

In the Grand Scheme of Things, removing things and making them
simpler seems a lofty goal. :-)   Anyone know of any pitfalls that
await me if I try to remove these sections, a la pmac and friends?

You'll probably get most objection from the PReP users, for whom
getting back a few hundred kB is a big deal.  (Maybe we should just
buy both of them a G5 or something. 8-)

OK.  I dug up some data.

Compiled ppc32 *_defconfig across the page.
Section down the left.  All numbers are 4K pages.
OF is the so-called "__openfirmware" section.


	pmac	ibmchrp	stx_gp3	mpc8555_cds
     	--------------------------------------
pmac	10	7	0	0
prep	2	2	0	0
chrp	1	1	0	0
OF	2	1	0	0
init	47	46	23	32

Over in arch/ppc/mm/init.c this gets done:

        printk ("Freeing unused kernel memory:");
        FREESEC(init);
        if (_machine != _MACH_Pmac)
                FREESEC(pmac);
        if (_machine != _MACH_chrp)
                FREESEC(chrp);
        if (_machine != _MACH_prep)
                FREESEC(prep);
        if (!have_of)
                FREESEC(openfirmware);

Toss sections that don't match your _machine.
Everyone tosses init section.
Embedded boards will take no hit.
Ppc64 currently does not have these special sections
    and hence will see no impact here.

That is the cost of removing these section identifiers.

So, is everyone prepared to live with these few pages
of occasional increased image size and remove the
special sections?

Thanks,
jdl

On Sep 15, 2005, at 6:09 AM, Paul Mackerras wrote:

Jon Loeliger writes:

quoted

In the Grand Scheme of Things, removing things and making them
simpler seems a lofty goal. :-)   Anyone know of any pitfalls that
await me if I try to remove these sections, a la pmac and friends?

You'll probably get most objection from the PReP users, for whom
getting back a few hundred kB is a big deal.  (Maybe we should just
buy both of them a G5 or something. 8-)

If they care that much they should submit a patch to build a PReP  
specific kernel that doesn't include this stuff.  And while you are  
buying G5's for people send one my way :)

I vote that we just get ride of this sections stuff for prep, pmac,  
of, chrp and if we want to reduce the code size make it a compile  
choice to build specific kernel's that dont include the crap that the  
others need.  (especially based on the numbers that Jon has posted  
for size).

- kumar

On Thu, Sep 15, 2005 at 09:09:48PM +1000, Paul Mackerras wrote:

Jon Loeliger writes:

quoted

In the Grand Scheme of Things, removing things and making them
simpler seems a lofty goal. :-)   Anyone know of any pitfalls that
await me if I try to remove these sections, a la pmac and friends?

You'll probably get most objection from the PReP users, for whom
getting back a few hundred kB is a big deal.  (Maybe we should just
buy both of them a G5 or something. 8-)

Well, we have something like 20 or 25 VME machines controlling 
experiments here, some with only 16Mb of RAM. The lifetime
of these systems is often of the order of 20 years (we shall
finally get rid of our TMS9900 processors with 32kB in November,
they were bought in 1982 I believe).

So yes, I object strongly object if I don't have a way 
of removing useless PMAC code. The kernel is already very 
bloated compared with the 2.2 we started with, which was 
well below 1MB with the minimal setup: serial console, root 
on NFS, no swap, some locally modules to control the PCI<->VME 
bridge and what is behind on the VME bus. 

	Gabriel

On Sep 15, 2005, at 4:57 PM, Gabriel Paubert wrote:

So yes, I object strongly object if I don't have a way
of removing useless PMAC code.

Or, any other code that isn't appropriate.  People have
always laughed at me for trying to save bytes here and
there, but I have to say there are many, many more PowerPCs
running Linux in 32M of memory than 2G of memory.

Using the smallest amount of memory to solve the
problem is still the norm, and when you are competing
against other architectures that can run in less memory,
you can't win.  Of course, as Gabriel said, I also see
legacy systems that want to change from another OS
to Linux, but they have 16M soldered on the board (which
was _way_ more than necessary to run that other OS),
and that isn't going to change.

Please, we have to be sensitive to configuring systems
to minimize the resource requirements for Linux.

Thanks.

	-- Dan

Gabriel Paubert writes:

So yes, I object strongly object if I don't have a way 
of removing useless PMAC code. The kernel is already very 
bloated compared with the 2.2 we started with, which was 
well below 1MB with the minimal setup: serial console, root 
on NFS, no swap, some locally modules to control the PCI<->VME 
bridge and what is behind on the VME bus. 

I assume you compile custom kernels for these machines, so you're
happy with using config options to remove the code you don't want?
Having the .pmac.text, .prep.text etc. sections lets us remove
unneeded code at runtime, but it sounds like that isn't actually the
issue for you (i.e. you don't have a need to run the same kernel on
both a pmac and a prep).

Paul.

On Fri, Sep 16, 2005 at 08:00:35AM +1000, Paul Mackerras wrote:

Gabriel Paubert writes:

quoted

So yes, I object strongly object if I don't have a way 
of removing useless PMAC code. The kernel is already very 
bloated compared with the 2.2 we started with, which was 
well below 1MB with the minimal setup: serial console, root 
on NFS, no swap, some locally modules to control the PCI<->VME 
bridge and what is behind on the VME bus. 

I assume you compile custom kernels for these machines, so you're
happy with using config options to remove the code you don't want?

Yes, and I have no problems with it. 

Actually I even wrote my own bootloader, which reorganizes the 
host bridge memory map to make the MVME 2400/2600 have a more 
CHRP-like map, like the MVME5100. The reason is that people 
with VME systems like sparsely populated huge memory space
and the 1GB IO space of Prep came in the way.

Actually I announced this bootloader on these lists a long 
time ago; Cort Dougan (the maintainer at the time) liked it
very much but I failed at pushing it. It had a few interesting
features: among them it could initialize a video board by 
executing the BIOS since it included an x86 emulator (24kB
code + data). It had a relatively clean memory management,
etc... 

But I have no time to work on it in the next few months.

Having the .pmac.text, .prep.text etc. sections lets us remove
unneeded code at runtime, but it sounds like that isn't actually the
issue for you (i.e. you don't have a need to run the same kernel on
both a pmac and a prep).

Not at all. For example my pmac kernels need usb to boot 
(literally), the MVME machines have CONFIG_USB off (this 
saves a lot).

Now there are other architectures that could be merged,
an example is PreP/PowerPlus/MVME5100. 

	Gabriel

On Thu, 2005-09-15 at 17:37, Gabriel Paubert wrote:

quoted

I assume you compile custom kernels for these machines, so you're
happy with using config options to remove the code you don't want?

Yes, and I have no problems with it. 

quoted

Having the .pmac.text, .prep.text etc. sections lets us remove
unneeded code at runtime, but it sounds like that isn't actually the
issue for you (i.e. you don't have a need to run the same kernel on
both a pmac and a prep).

Not at all. For example my pmac kernels need usb to boot 
(literally), the MVME machines have CONFIG_USB off (this 
saves a lot).

Now there are other architectures that could be merged,
an example is PreP/PowerPlus/MVME5100. 

	Gabriel

Hi Gabriel,

I am reading this to mean that you then have no issue with
my proposed changes of removing the special handling of
the .pmac, .prep, .chrp, and .openfirmware sections that
really only apply to MULTIPLATFORM built images.

Again, for embedded boards and for custom-built configurations,
this change really should have no impact on your image size.

So, were there other objects I missed?  If not, I will
proceed with a patch to remove these special sections
so that we may merge the sections.h header file better!

Thanks!
jdl

So yes, I object strongly object if I don't have a way 
of removing useless PMAC code. The kernel is already very 
bloated compared with the 2.2 we started with, which was 
well below 1MB with the minimal setup: serial console, root 
on NFS, no swap, some locally modules to control the PCI<->VME 
bridge and what is behind on the VME bus. 

I think we should have the ability to not build some platforms like we
have on ppc64. That would allow you to build a PReP kernel without CHRP
and PMAC code.

Ben.