From: Sam Ravnborg <sam@ravnborg.org>
To: Guan Xuetao <guanxuetao@mprc.pku.edu.cn>
Cc: 'Paul Mundt' <lethal@linux-sh.org>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv1 01/12] unicore32 core architecture: build infrastructure
Date: Sat, 8 Jan 2011 08:20:53 +0100 [thread overview]
Message-ID: <20110108072053.GA10552@merkur.ravnborg.org> (raw)
In-Reply-To: <023601cbaef7$850f2af0$8f2d80d0$@mprc.pku.edu.cn>
Hi Guan.
A few nits.
> +# Explicitly specifiy 32-bit UniCore ISA:
> +KBUILD_CFLAGS +=$(call cc-option,-municore32)
If gcc does not support -municore32 then I assume it
is a wrong gcc version used.
So just add it unconditionally.
The cc-option macro is used to add options to gcc iff gcc
supports this option. So each time you use cc-option we
actually run gcc to determine if the opton is supported.
Also as a general rule add a space after the equal sign:
> +KBUILD_CFLAGS += -municore32
^
> +
> +#Default value
> +head-y := arch/unicore32/kernel/head.o arch/unicore32/kernel/init_task.o
Break longer lines in two like this:
> +head-y := arch/unicore32/kernel/head.o
> +head-y += arch/unicore32/kernel/init_task.o
Note: I see lots of Makefile where longer lines are continued on
the next line using a '\'. But like in regular C code to use an incremental
assignment looks just better / is more clear.
> +textofs-y := 0x00408000
> +
> +# The byte offset of the kernel image in RAM from the start of RAM.
> +TEXT_OFFSET := $(textofs-y)
If you are going to have different TEXT_OFFSET's then I suggest to move
this to KConfig as an "hex "Text offset" config option.
You can set default values dependign on BSP etc.
Also defiing stuff here just to export it for use in boot/
has always looked like a strange concept - but many archs do so today.
You do not export TEXT_OFFSET but I guess this is a bug?
> +
> +export TEXT_OFFSET GZFLAGS
This variable is never used.
> +
> +core-y += arch/unicore32/kernel/ arch/unicore32/mm/
> +core-$(CONFIG_UNICORE_FPU_F64) += arch/unicore32/uc-f64/
> +
> +drivers-$(CONFIG_ARCH_PUV3) += drivers/staging/puv3/
> +
> +libs-y += arch/unicore32/lib/
> +# include libc.a in libs-y for string functions, like memcpy and so on.
> +libs-y += $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libc.a)
> +libs-y += $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libgcc.a)
> +
The other three archs that uses libgcc use:
$(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
So when I read the above I am confused why it looks different than the others.
For libc I guess you do nto have that option and what you do is fine there.
> +
> +CLEAN_FILES += $(ASM_GENERIC_HEADERS)
> +
> +# We use MRPROPER_FILES and CLEAN_FILES now
Stale comment
> + echo ' Install using (your) ~/bin/$(INSTALLKERNEL) or'
> + echo ' (distribution) /sbin/$(INSTALLKERNEL) or'
> + echo ' install to $$(INSTALL_PATH) and run lilo'
I do not think the three lines above is correct for unicore32.
Looks like they are left from a copy from x86.
Sam
next prev parent reply other threads:[~2011-01-08 7:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-25 18:41 [PATCHv1 01/12] unicore32 core architecture: build infrastructure Guan Xuetao
2011-01-06 7:55 ` Paul Mundt
2011-01-08 5:47 ` Guan Xuetao
2011-01-08 7:20 ` Sam Ravnborg [this message]
2011-01-08 11:09 ` Guan Xuetao
2011-01-08 11:09 ` Guan Xuetao
2011-01-08 11:48 ` Sam Ravnborg
2011-01-08 11:48 ` Sam Ravnborg
2011-01-10 12:12 ` Guan Xuetao
2011-01-10 12:34 ` Sam Ravnborg
2011-01-07 0:18 ` Arnd Bergmann
2011-01-07 0:18 ` Arnd Bergmann
2011-01-08 9:22 ` Guan Xuetao
2011-01-08 14:07 ` Sam Ravnborg
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=20110108072053.GA10552@merkur.ravnborg.org \
--to=sam@ravnborg.org \
--cc=guanxuetao@mprc.pku.edu.cn \
--cc=lethal@linux-sh.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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).