public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] ARM: S3C64XX: add support for mini6410
Date: Wed, 01 Dec 2010 07:42:00 +0100	[thread overview]
Message-ID: <4CF5EE38.8050901@free.fr> (raw)
In-Reply-To: <AANLkTik6p6Ug2eMwmuDcOwFu6W3-WarYvhaCo788OViQ@mail.gmail.com>

Hi Darius,

Le 30/11/2010 10:19, Darius Augulis a ?crit :

> I understand, that there is such rule in u-boot, but it's ... at least strange.
> Even linux kernel doesn't use such approach and uses simple defines instead.
> One big disadvantage for already existing platforms - one must convert
> all defines to C structure.

These rules apply to new code; existing code can just remain the same, 
precisely to avoid rewrites.

> Remove almost everything from header file, because no need to have
> duplicated code.

?

> And what about code porting between linux kernel and u-boot? With
> definitions in header file it's easy copy paste procedure.

There are exceptions for code ported from Linux, IIRC.

> What if I need two registers separated with big gap from one big 100
> register bank? Then I need to build huge C structure with many dummy
> variables.

That's only one dummy variable, an array of 100 elements. Plus it 
*shows* there is a gap, which when dealing with datasheets is a plus.

> Lot of lines... In this case, possibility to make a dummy
> error is bigger. IMHO C structure for register definition is not
> better than definitions in header file. It's worse.
> We could have much tiny, simply and more readable code with definition
> in header file. And this approach has been used for years and still
> used in linux kernel. Perhaps, not without reason...

One of the interests of C structs is that they guarantee against errors 
in typing register offsets, for instance.

> If u-boot maintainers are really going not accept this patch because
> of this, I will change it. But it's meaningless and very annoying.

Please bear with it, just like we all bear with e.g. coding style rules 
from checkpatch.pl even though we would personally do it another way.

> thanks,
> Darius

Amicalement,
-- 
Albert.

  reply	other threads:[~2010-12-01  6:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-17 21:26 [U-Boot] [RFC PATCH] ARM: S3C64XX: add support for mini6410 Darius Augulis
2010-11-22 18:28 ` Darius Augulis
2010-11-23  0:03   ` Minkyu Kang
2010-11-30  0:49 ` Minkyu Kang
2010-11-30  8:17   ` Darius Augulis
2010-11-30  8:50     ` Minkyu Kang
2010-11-30  9:19       ` Darius Augulis
2010-12-01  6:42         ` Albert ARIBAUD [this message]
2010-12-02 20:10           ` Darius Augulis

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=4CF5EE38.8050901@free.fr \
    --to=albert.aribaud@free.fr \
    --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