From: Gabriel Paubert <paubert@iram.es>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc64-dev <linuxppc64-dev@ozlabs.org>,
Arnd Bergmann <arnd@arndb.de>,
"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Re: PATCH powerpc: Merge asm-ppc*/sections.h
Date: Fri, 16 Sep 2005 00:37:02 +0200 [thread overview]
Message-ID: <20050915223702.GA322@iram.es> (raw)
In-Reply-To: <17193.61187.613745.15444@cargo.ozlabs.ibm.com>
On Fri, Sep 16, 2005 at 08:00:35AM +1000, Paul Mackerras wrote:
> 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?
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
next prev parent reply other threads:[~2005-09-15 22:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-13 20:43 PATCH powerpc: Merge asm-ppc*/sections.h Jon Loeliger
2005-09-14 2:35 ` Arnd Bergmann
2005-09-14 13:46 ` Jon Loeliger
2005-09-15 11:09 ` Paul Mackerras
2005-09-15 17:07 ` Jon Loeliger
2005-09-15 17:28 ` Kumar Gala
2005-09-15 20:57 ` Gabriel Paubert
2005-09-15 21:21 ` Dan Malek
2005-09-15 22:00 ` Paul Mackerras
2005-09-15 22:37 ` Gabriel Paubert [this message]
2005-09-16 14:46 ` Jon Loeliger
2005-09-18 1:28 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050915223702.GA322@iram.es \
--to=paubert@iram.es \
--cc=arnd@arndb.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc64-dev@ozlabs.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).