From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] Code style questions (weak functions, cpu/ v's lib_arch/)
Date: Tue, 18 Nov 2008 17:54:56 -0500 [thread overview]
Message-ID: <200811181754.57367.vapier@gentoo.org> (raw)
In-Reply-To: <d66caabb0811181435q76692816x5478cee9481bd133@mail.gmail.com>
On Tuesday 18 November 2008 17:35:04 Graeme Russ wrote:
> 1) I have seen two varying applications of __attribute__ ((weak)) - The
> most common being of the form:
>
> function(args) __attribute__((weak,alias("__function")));
> __function(args)
> {
> /* Default functionality */
> };
>
> The other is rare (occurs only 5 times in my slightly older code base)
> __attribute__((weak))
> function(args)
> {
> /* Default functionality */
> };
>
> Is there any real difference between the two?
depends on how they're used. the former gives you two symbols: one weak and
one strong. the latter gives you one weak symbol. if you talk about tricky
scenarios (like internal C library magic), then there would be a real case for
the former. in a static binary like u-boot, i dont believe there's any
functional difference in the resulting binary.
> Is there a reason for the second one?
matter of style for the most part i think. the former allows a whole bunch of
symbols to be declared weak in one place. the latter can require weak
markings spread out over the source tree.
> 2) What defines if code belongs in cpu/<cpu_type> versus lib_<cpu_type>?
> Reset vector and bootstrap code is fairly obvious, but I notice that
> serial port functionality seems to be exclusively located in
> cpu/<cpu_type>, interrupt handling seems to be a bit of a mix depending on
> the particular cpu, lib_nios2\cache.S and lib_ppc\cache.c (to me) in an
> odd location.
it's lib_<arch>/ and cpu/<cpu>/, not lib_<cpu>. architecture-level things go
into lib_<arch>/ while cpu-specific things go into cpu/<cpu>/. this probably
gets pretty blurry in cases where there arent many cpu implementations for an
arch. like the NIOS. but when you look at say ARM, each ARM cpu has
drastically different behavior with things like the interrupt controller, or
initial init, or resetting, but they all tend to be the same (or very similar)
at the basic architecture level.
> Are there any hard and fast rules I should be using to increase the chances
> of these changes making it into mainline more smoothly?
i doubt it. the only hard & fast rule is dont make Wolfgang disagreeable.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20081118/5e06d589/attachment-0001.pgp
next prev parent reply other threads:[~2008-11-18 22:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-18 22:35 [U-Boot] Code style questions (weak functions, cpu/ v's lib_arch/) Graeme Russ
2008-11-18 22:54 ` Mike Frysinger [this message]
2008-11-19 17:23 ` Jon Loeliger
2008-11-19 18:52 ` Wolfgang Denk
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=200811181754.57367.vapier@gentoo.org \
--to=vapier@gentoo.org \
--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.