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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.