linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: Matt Porter <mporter@kernel.crashing.org>
Cc: Embedded Linux PPC list <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: random ramblings on 8xx patches (long and tedious :-)
Date: Fri, 23 Jul 2004 08:34:54 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.60.0407230821050.4487@localhost.localdomain> (raw)
In-Reply-To: <20040722104621.B17686@home.com>


On Thu, 22 Jul 2004, Matt Porter wrote:

> On Thu, Jul 22, 2004 at 08:00:01AM -0400, Robert P. J. Day wrote:
>
> [Remove long explanation]
>
>>    thoughts?  i'm willing to help with menu reorg -- my only
>> contribution to the 2.6 kernel was to thoroughly restructure the
>> "Filesystems" menu.  which means i like it, and i don't care what
>> *you* think. ;-)
>
> You raise a lot of interesting concerns on usability for a newbie.
> Descriptive menu options with useful help info are a good thing.
> Please send a patch with your proposed changes so it can be reviewed.

the first addition i'd like to see is a set of extra conditionals
added to arch/ppc/config.in, to refine the type of processor.  in some
cases, it's not enough to know that you have an 8xx, and it's *too*
refined to know that you have, say, a TDM850M.  sometimes, you need to
know only that you have an 823, or 850, or whatever.

perhaps variables:

   CONFIG_8xx_823
   CONFIG_8xx_850
   CONFIG_8xx_860

or alternatively named

   CONFIG_PPC_823
   CONFIG_PPC_850

and so on.  i've already seen code in the kernel tree (can't remember
where, sadly) that goes through a tedious preprocessor check when all
it wanted to know was the actual processor.  and all of this extra
checking and setting could be done entirely within the
arch/ppc/config.in file, with no harm to other files or small animals.
(i suspect the same might hold true for 4xx, 6xx and others, but i
haven't looked at those yet.)

i can't design this patch just yet, as i'm not sure how many different
variants are worth keeping track of.  if there's a list someone could
point me at, that would be just ducky.

rday

p.s.  sadly, there's some inconsistency in the way the current
variable names were chosen.  in that same file, we have both of
CONFIG_8xx and CONFIG_PPC_5xxx.  even thought it's more verbose, it
might have been safer to keep that "PPC" internal string to avoid
potential conflicts.  so it's a tossup as to what variable name would
be the best choice to identify an 850:

   CONFIG_850
   CONFIG_PPC_850
   CONFIG_8xx_850

thoughts?  yes, this is just me being pedantic.  it gets worse. :-)


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2004-07-23 12:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-22 12:00 random ramblings on 8xx patches (long and tedious :-) Robert P. J. Day
2004-07-22 17:46 ` Matt Porter
2004-07-23 12:34   ` Robert P. J. Day [this message]
2004-07-23 13:36     ` Wolfgang Denk
2004-07-23 14:09       ` Robert P. J. Day
2004-07-23 14:56         ` Wolfgang Denk
     [not found]         ` <410123EE.4000602@intracom.gr>
2004-07-23 15:56           ` Mark Chambers
2004-07-23 17:22           ` Wolfgang Denk
2004-07-23 21:06             ` Linux is not reliable enough? Kevin P. Dankwardt
2004-07-24  3:02               ` Linh Dang
2004-07-24  6:29                 ` Der Herr Hofrat
2004-07-25 16:23                 ` Wolfgang Denk
2004-07-24 11:35               ` Mark Chambers
2004-07-24 22:14                 ` MPC8245 Error No. 26 DeLaGarza, Robert
2004-07-26  7:49                 ` Linux is not reliable enough? Marius Groeger
2004-07-26 13:46                   ` Mark Chambers
2004-07-26 14:31                     ` Der Herr Hofrat
2004-07-26 15:42                     ` Marius Groeger
2004-07-27 11:20                     ` Robert Kaiser
2004-07-27 13:29                       ` Mark Chambers
2004-07-24 21:44               ` Sylvain Munaut
2004-07-25  3:00             ` Could 2_4_devel support RPXlite DW LCD panel? Song Sam
  -- strict thread matches above, loose matches on Subject: below --
2004-07-22 17:10 random ramblings on 8xx patches (long and tedious :-) Wells, Charles
2004-07-22 17:35 ` Dan Malek
2004-07-23  8:48   ` Jaap-Jan Boor

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=Pine.LNX.4.60.0407230821050.4487@localhost.localdomain \
    --to=rpjday@mindspring.com \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=mporter@kernel.crashing.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).