linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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/

      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).