From: Adrian Cox <apc@agelectronics.co.uk>
To: Dan Malek <dan@netx4.com>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: PowerPC BOF at Ottawa Linux Symposium July 19
Date: Tue, 13 Jun 2000 11:33:48 +0100 [thread overview]
Message-ID: <39460E0C.CBEE73AD@agelectronics.co.uk> (raw)
In-Reply-To: 39453A10.55C5F4D6@embeddededge.com
Dan Malek wrote:
> As a workstation/server BOF, I don't know how much interest exists to
> discuss this. The easy answer is a set of orthogonal directory trees,
> but I think the highest priority should be on maintaining a set of
> common files. Having experienced splitting some processor dependent
> files, I would still take the #ifdefs over tracking similar changes
> across multiple files.
I'd go with that some of the way, but I think MMU_init() in mm/init.c
goes a bit too far. It feels like every time I port my patches to a new
release kernel somebody has added extra boards and I have to sort switch
statements out by hand.
As an example, looking at 2.2 and 2.3, the actions performed by
xxx_find_end_of_memory() haven't changed very much. There probably
wouldn't be much problem introducing a ppc_md.find_end_of_memory call(),
and patches to add new machines would apply much cleaner.
I don't think the world is ready for my dream of eliminating _machine
completely, but if there's any interest I can attempt a test refactoring
of mm/init.c. This needn't be an all at once change; the idiom I'm
thinking of goes something like:
if (ppc_md.do_whatever())
ppc_md.do_whatever();
else {
#ifndef CONFIG_8xx
switch(_machine)
...
#else
8xx_do_whatever();
#endif
}
- Adrian Cox, AG Electronics
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
prev parent reply other threads:[~2000-06-13 10:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-09 19:03 PowerPC BOF at Ottawa Linux Symposium July 19 rodgersg
2000-06-11 0:20 ` Cort Dougan
2000-06-12 19:29 ` Dan Malek
2000-06-13 10:33 ` Adrian Cox [this message]
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=39460E0C.CBEE73AD@agelectronics.co.uk \
--to=apc@agelectronics.co.uk \
--cc=dan@netx4.com \
--cc=linuxppc-dev@lists.linuxppc.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).