2GB address space limit on 32-bit PowerPC Macintosh
Benjamin Herrenschmidt
benh at kernel.crashing.org
Tue May 17 10:54:47 EST 2005
> Who cares? We have the ability to support the memory map flexibility
> for everyone. If you need it, use it, and fix it if necessary. There
> are
> too many other things that need attention. Again, you are taking one
> of the features we added for embedded boards a long time ago, and
> demanding everyone support it.
Gack ? None of this was 'added for embedded boards'. The initial 2G/2G
split was Cort's decision afaik for the PReP port, and it was PReP and
pmac that introduced the use of BATs for IO mappings, which then got
turned into io_block_mapping() for clarity. Those platorms predate by
far any embedded involvement in the ppc kernel.
> That's not necessary. If you want
> to use this feature on a PMac, then use it, but please don't demand
> everyone else do so. We didn't do that when the feature was added.
It's more than a "feature", it's the way it should have been done in the
first place on 6xx/7xx/7xxx CPUs and wasn't done because of a cheap hack
for IO mapping. I have no problem with other CPU family maintainers
deciding to restrict TASK_SIZE for the sake of saving a couple of
instructions (on 4xx, it's really replacing andis.;beq with
rlwinm;cmpl;bne or something like that, so one instruction, to support
any TASK_SIZE).
> > The whole io_block_mapping() was a bad idea in the first place.
>
> All of the ideas in 2.6 are going to look like bad ideas in the future
> :-)
Hrm... If you say so ...
> It's what worked and was necessary given the lack of any other
> APIs at the time.
ioremap and variants was available at this time and has always been.
> We are working on removing these in the embedded
> boards, and it has to be done on the PMac as well if you want to
> take advantage of something other than a 2G task space.
Well, you know what ? I've removed them from pmac a long time ago :) And
you know what also ? what you just stated above is _exactly_ what this
thread is all about ... so what are you complaining about ? :)
> As time permits, I will make whatever changes to the board ports
> I'm aware of so they will accommodate a 3G task space, or fix up
> the configuration files so the default is 2G. At some point, we can
> make it the configuration default.
Good, I'm not asking for anything else here.
Ben.
More information about the Linuxppc-dev
mailing list