public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?
Date: Mon, 28 Jun 2004 13:37:36 +0200	[thread overview]
Message-ID: <20040628113741.31CF8C109F@atlas.denx.de> (raw)
In-Reply-To: Your message of "Mon, 28 Jun 2004 12:51:02 +0200." <20040628105102.GB14287@pengutronix.de>

In message <20040628105102.GB14287@pengutronix.de> you wrote:
> On Mon, Jun 28, 2004 at 11:35:01AM +0200, Wolfgang Denk wrote:
> > In U-Boot we just split in "cpu" and "board". 
> 
> Which is no good idea. CPU is ARM920T and each and every board copies
> everything it needs from other boards.

Feel free to make a suggestion how to deal with this in a better way.

> Is there any activity to work on a "next generation u-boot" which avoids
> all the design glitches we currently have? It's nearly impossible to

Maybe as a first step we should start collecting such design glitches?

> restructure things in a tree which is supposed to be production code. I
> think of things like config frontend, everybody-is-alowed-to-add-tons-
> of-trailing-whitespace-if-he-is-not-robert, layered drivers which hold
> their pointers to the hardware in structures instead of 1001 ifdefs etc. 

Re config frontend: is there any new stuff  available  that  I  don't
   know  of?  We had this discusssion a couple of times before, but I
   haven't seen any working code or  implementation  example  yet.  I
   cannot make comments on things I have never seen.

Re everybody-is-alowed-to-add-tons-of-trailing-whitespace-if-he-is-not-robert:
   I can understand that you feel frustrated, as you hold the  record
   of  having patches rejected because of violating the Coding Style.
   To make it clear: there are no  exceptions  from  the  rules.  The
   coding  style applies to everybody. For small patches I may decide
   to perform the cleanup myself, especially  for  people  submitting
   their first few patches. This is mostly to encourage them to go on
   contributing  their work back to the community. From netheads like
   you I expect a little more. OK, everybody can miss a thing here or
   there. But your patches violate the Coding Style in a density that
   I can only call ignorance. I am not  in  the  mood  to  accept  an
   attitude  like  "it  is difficult to audit this patch for trailing
   whitespace as the patch context contains that  much"  -  there  is
   only  a single file in the CVS which contains trailing while space
   (and this  is  the  automatically  generated  include/bmp_logo.h).
   Sorry - the context is clean, so please cleanup your patch, too.

Re layered drivers:
   Please feel free to submit patches.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
As far as we know, our computer has never had an undetected error.
		                                           -- Weisert

  reply	other threads:[~2004-06-28 11:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-27 11:25 [U-Boot-Users] nomen est omen: i.MX or mc9329 ? Steven Scholz
2004-06-27 18:18 ` [U-Boot-Users] " Robert Schwebel
2004-06-28  7:11   ` Steven Scholz
2004-06-28  7:19     ` llandre
2004-06-28  9:20       ` Robert Schwebel
2004-06-28  9:31         ` Steven Scholz
2004-06-28  9:35         ` Wolfgang Denk
2004-06-28 10:51           ` Robert Schwebel
2004-06-28 11:37             ` Wolfgang Denk [this message]
2004-06-28 12:38               ` Robert Schwebel
2004-06-28 14:10                 ` Wolfgang Denk
2004-06-28 14:17                   ` Steven Scholz
2004-06-28 12:14             ` Steven Scholz
2004-06-28 13:01               ` Robert Schwebel
2004-06-28 15:15                 ` Sascha Hauer
2004-06-28  9:57         ` llandre
2004-06-28 10:09           ` Steven Scholz
2004-06-28 11:07             ` llandre

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=20040628113741.31CF8C109F@atlas.denx.de \
    --to=wd@denx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox