* *_find_end_of_memory Mach Dep?
@ 2000-01-14 20:51 Grant Erickson
2000-01-14 22:31 ` Dan Malek
0 siblings, 1 reply; 4+ messages in thread
From: Grant Erickson @ 2000-01-14 20:51 UTC (permalink / raw)
To: linuxppc-dev
Instead of having a mess of ifdef's and such in MMU_init for {apus, pmac,
m8xx, oak, chrp, etc}_find_end_of_memory, is there any compelling reason
not to make a ppc_md machine dependency entry for these?
If no one is in disagreement, I'd like to put a patch together for it.
Regards,
Grant
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: *_find_end_of_memory Mach Dep?
[not found] <387F8EB3.B8098131@mitre.org>
@ 2000-01-14 21:07 ` Grant Erickson
2000-01-14 22:34 ` Dan Malek
0 siblings, 1 reply; 4+ messages in thread
From: Grant Erickson @ 2000-01-14 21:07 UTC (permalink / raw)
To: Charles Lepple; +Cc: linuxppc-dev
On Fri, 14 Jan 2000, Charles Lepple wrote:
> Grant Erickson wrote:
> >
> > Instead of having a mess of ifdef's and such in MMU_init for {apus, pmac,
> > m8xx, oak, chrp, etc}_find_end_of_memory, is there any compelling reason
> > not to make a ppc_md machine dependency entry for these?
>
> When I converted some code to the ppc_md interface, I seem to remember a
> few cases where I couldn't do it that way because the ppc_md structure
> was not completely filled out. It can get to be a catch-22 -- there has
> to be one messy function.
Fair enough. However, since identify_machine is called before MMU_init and
<platform>_init is called in identify_machine, then it's reasonable that
the ppc_md structure is filled out by the time we hit MMU_init.
So, it seems reasonable that "identify_machine" remains the messy
function and MMU_init could be cleaned up somewhat.
Grant
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: *_find_end_of_memory Mach Dep?
2000-01-14 20:51 Grant Erickson
@ 2000-01-14 22:31 ` Dan Malek
0 siblings, 0 replies; 4+ messages in thread
From: Dan Malek @ 2000-01-14 22:31 UTC (permalink / raw)
To: Grant Erickson; +Cc: linuxppc-dev
Grant Erickson wrote:
>
> Instead of having a mess of ifdef's and such in MMU_init for {apus, pmac,
> m8xx, oak, chrp, etc}_find_end_of_memory, is there any compelling reason
> not to make a ppc_md machine dependency entry for these?
I didn't see a mess of ifdef's.....in fact a ppc_md entry wouldn't
change the ifdef's, it would just remove a couple of lines of code
in MMU_init().
I put the ifdef's there originally to remove lots of code from the 8xx
port that isn't needed. Perhaps with your 40x stuff we should consider
a more modular MMU_init() instead of the ifdef's, like creating multiple
mm/xxx_init.c files for the different MMU configurations (I can't believe
I said this, as I hate multiple files like this :-).
> If no one is in disagreement, I'd like to put a patch together for it.
Let's see what it looks like........
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: *_find_end_of_memory Mach Dep?
2000-01-14 21:07 ` *_find_end_of_memory Mach Dep? Grant Erickson
@ 2000-01-14 22:34 ` Dan Malek
0 siblings, 0 replies; 4+ messages in thread
From: Dan Malek @ 2000-01-14 22:34 UTC (permalink / raw)
To: Grant Erickson; +Cc: Charles Lepple, linuxppc-dev
Grant Erickson wrote:
> On Fri, 14 Jan 2000, Charles Lepple wrote:
> > When I converted some code to the ppc_md interface, I seem to remember a
> > few cases where I couldn't do it that way because the ppc_md structure
> > was not completely filled out. It can get to be a catch-22 -- there has
> > to be one messy function.
I already checked this before I sent my reply, and it should work fine.
> So, it seems reasonable that "identify_machine" remains the messy
> function and MMU_init could be cleaned up somewhat.
It only looks messy because you haven't seen it grow over the years :-).
I think it is aging rather gracefully.....
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-01-14 22:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <387F8EB3.B8098131@mitre.org>
2000-01-14 21:07 ` *_find_end_of_memory Mach Dep? Grant Erickson
2000-01-14 22:34 ` Dan Malek
2000-01-14 20:51 Grant Erickson
2000-01-14 22:31 ` Dan Malek
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).