All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] cmd_bdinfo: move implementation to arch	instead of common
Date: Wed, 12 Nov 2008 17:31:01 +0100	[thread overview]
Message-ID: <20081112163101.GE7014@game.jcrosoft.org> (raw)
In-Reply-To: <1aad82fa0811120817l163326adwec35a1ebeb08735@mail.gmail.com>

 >
> > Hi Jean-Christophe,
> >
> > Is this a good idea?  It takes one centralized mess (that is deprecated,
> > but we don't have a good track record of death after deprecation) and
> > spreads it out over a bunch of files.  Reminds me of cancer.  :-(
> >
> > The centralized mess had no duplication of code, but a lot of #ifdef
> > ugly.  This patch trades off the removal of most of the #ifdef ugly for
> > a lot of duplication.  Which is the lesser of two evils?
> >
> > If you continue down the fragmentation path, would it work to keep the
> > primary bdinfo command (cmd_bdinfo.c) and add two weak function calls to
> > it that processor families and boards can hook to add in their extra
> > processor- and board-specific stuff?  This may result in some
> > rearrangement of the print output (which I don't view as a problem, but
> > manual writers might not like it).  It also results in some additional
> > obscurity since a processor/board porter needs to understand that there
> > is an additional hook to grab for customization.
> 
> i think the split version proposed is a lot nicer than the current
> one, but going the route of having an arch hook would be best.  i dont
> think we even need a weak function ... force every arch to implement
> *something*.
It's the case
The idea is to allow soc and board to allow them to print more info

Best Regards,
J.

  reply	other threads:[~2008-11-12 16:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-11 20:54 [U-Boot] [PATCH] cmd_bdinfo: move implementation to arch instead of common Jean-Christophe PLAGNIOL-VILLARD
2008-11-12 14:02 ` Jerry Van Baren
2008-11-12 14:57   ` Jean-Christophe PLAGNIOL-VILLARD
2008-11-12 19:13     ` [U-Boot] [PATCH V2] " Jean-Christophe PLAGNIOL-VILLARD
2008-11-12 19:36       ` Mike Frysinger
2008-11-12 19:45         ` Jean-Christophe PLAGNIOL-VILLARD
2008-11-12 19:55           ` Mike Frysinger
2008-11-12 20:06             ` Jean-Christophe PLAGNIOL-VILLARD
2008-12-04 12:29       ` [U-Boot] [PATCH V3] " Jean-Christophe PLAGNIOL-VILLARD
2008-12-04 12:35         ` [U-Boot] [PATCH V4] " Jean-Christophe PLAGNIOL-VILLARD
2008-12-04 13:36           ` Joakim Tjernlund
2008-11-13  8:15     ` [U-Boot] [PATCH] " Haavard Skinnemoen
2008-11-12 16:17   ` Mike Frysinger
2008-11-12 16:31     ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2008-11-12 17:55       ` Mike Frysinger
2008-11-12 18:08         ` Jean-Christophe PLAGNIOL-VILLARD
2008-11-12 18:16           ` Mike Frysinger

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=20081112163101.GE7014@game.jcrosoft.org \
    --to=plagnioj@jcrosoft.com \
    --cc=u-boot@lists.denx.de \
    /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.