Use the standard obj-y form to specify the sub-directories under
arch/riscv/. No functional change intended.
Signed-off-by: Masahiro Yamada <[email protected]>
---
arch/riscv/Kbuild | 3 +++
arch/riscv/Makefile | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/Kbuild
diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild
new file mode 100644
index 000000000000..d1d0aa70fdf1
--- /dev/null
+++ b/arch/riscv/Kbuild
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-y += kernel/ mm/ net/
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 426d989125a8..bf4c6d914ff5 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -72,7 +72,7 @@ KBUILD_IMAGE := $(boot)/Image.gz
head-y := arch/riscv/kernel/head.o
-core-y += arch/riscv/kernel/ arch/riscv/mm/ arch/riscv/net/
+core-y += arch/riscv/
libs-y += arch/riscv/lib/
--
2.17.1
On Wed, Aug 21, 2019 at 06:26:58PM +0900, Masahiro Yamada wrote:
> Use the standard obj-y form to specify the sub-directories under
> arch/riscv/. No functional change intended.
>
> Signed-off-by: Masahiro Yamada <[email protected]>
Do you have a document what the grand scheme here is? Less of the magic
in arch/$(ARCH)/Makefile sounds like a good idea, but unless we have
a very specific split between the kbuild makefile and various override
I fear just splitting things up into two files doesn't really help much.
On Mon, Aug 26, 2019 at 8:35 PM Christoph Hellwig <[email protected]> wrote:
>
> On Wed, Aug 21, 2019 at 06:26:58PM +0900, Masahiro Yamada wrote:
> > Use the standard obj-y form to specify the sub-directories under
> > arch/riscv/. No functional change intended.
> >
> > Signed-off-by: Masahiro Yamada <[email protected]>
>
> Do you have a document what the grand scheme here is?
There is a small documentation about "Makefile" vs "Kbuild"
in Documentation/kbuild/modules.rst section 3.2
It is talking about external modules, but the benefit applies
to arch/$(SRCARCH)/Kbuild as well.
arch/$(SRCARCH)/Makefile is included by the top Makefile
to specify arch-specific compiler flags, etc.
On the other hand, arch/$(SRCARCH)/Kbuild, if exists, is included
when Kbuild actually descends into arch/$(SRCARCH)/.
This allows you to hierarchize the sub-directories to visit
instead of specifying everything in flat in arch/$(SRCARCH)/Makefile.
Major architectures are already doing this.
See
arch/x86/Kbuild
arch/sparc/Kbuild
arch/powerpc/Kbuild
etc.
(and arm64 also adopted this recently)
The trick is "Kbuild" has precedence over "Makefile".
If you are interested in the actual code,
see line 41 of scripts/Makefile.build
> Less of the magic
> in arch/$(ARCH)/Makefile sounds like a good idea, but unless we have
> a very specific split between the kbuild makefile and various override
> I fear just splitting things up into two files doesn't really help much.
Why not?
--
Best Regards
Masahiro Yamada
On Tue, Aug 27, 2019 at 02:14:59PM +0900, Masahiro Yamada wrote:
> There is a small documentation about "Makefile" vs "Kbuild"
> in Documentation/kbuild/modules.rst section 3.2
I know that part.
>
> It is talking about external modules, but the benefit applies
> to arch/$(SRCARCH)/Kbuild as well.
I fail to fully understand this part, though.
> arch/$(SRCARCH)/Makefile is included by the top Makefile
> to specify arch-specific compiler flags, etc.
>
> On the other hand, arch/$(SRCARCH)/Kbuild, if exists, is included
> when Kbuild actually descends into arch/$(SRCARCH)/.
>
> This allows you to hierarchize the sub-directories to visit
> instead of specifying everything in flat in arch/$(SRCARCH)/Makefile.
Yes, but what is the plan in the long run? arch/$(ARCH)/Makefile
is still a weird hodge-podge of overriding global variables and misc
Makefile targets, it now just has a tiny little work. Is there any
actual benefit from using Kbuild for the build process? Can we
eventually move the setting of variables in the Makefile into another
special purpose file? Is the support for actually compiling kernel
source files from the arch/$(ARCH) Makefile eventually going away?
On Wed, 21 Aug 2019, Masahiro Yamada wrote:
> Use the standard obj-y form to specify the sub-directories under
> arch/riscv/. No functional change intended.
>
> Signed-off-by: Masahiro Yamada <[email protected]>
Thanks, queued for v5.4-rc1.
- Paul
On Sat, Aug 31, 2019 at 12:53 AM Christoph Hellwig <[email protected]> wrote:
>
> On Tue, Aug 27, 2019 at 02:14:59PM +0900, Masahiro Yamada wrote:
> > There is a small documentation about "Makefile" vs "Kbuild"
> > in Documentation/kbuild/modules.rst section 3.2
>
> I know that part.
>
> >
> > It is talking about external modules, but the benefit applies
> > to arch/$(SRCARCH)/Kbuild as well.
>
> I fail to fully understand this part, though.
Kbuild support two file names, "Makefile" and "Kbuild"
for describing obj-y, obj-m, etc.
If both exist in the same directory, "Kbuild" takes precedence.
This is useful where we want to use "Makefile"
for other purposes.
For external modules, we use "Makefile" as a start point,
so we often want to describe obj-m in "Kbuild" instead of "Makefile".
Similarly, arch/$(SRCARCH)/Makefile is very special
in that it is included from the top-level Makefile,
and specify arch-specific compiler flags etc.
We can use arch/$(SRCARCH)/Kbuild
to specify obj-y, obj-m.
The top-level Makefile does not need to know
the directory structure under arch/$(SRCARCH)/.
This is logical separation.
>
> > arch/$(SRCARCH)/Makefile is included by the top Makefile
> > to specify arch-specific compiler flags, etc.
> >
> > On the other hand, arch/$(SRCARCH)/Kbuild, if exists, is included
> > when Kbuild actually descends into arch/$(SRCARCH)/.
> >
> > This allows you to hierarchize the sub-directories to visit
> > instead of specifying everything in flat in arch/$(SRCARCH)/Makefile.
>
> Yes, but what is the plan in the long run? arch/$(ARCH)/Makefile
> is still a weird hodge-podge of overriding global variables and misc
> Makefile targets, it now just has a tiny little work.
There are lots of arch-specific build settings.
We definitely need a place to describe them,
hence arch/$(SRCARCH)/Makefile.
> Is there any
> actual benefit from using Kbuild for the build process?
For example, arch/x86/Kbuild is quite useful
since there are many directories in arch/x86.
riscv does not have many directories for now since it is a new architecture,
but it will be useful when it will have more directories.
> Can we
> eventually move the setting of variables in the Makefile into another
> special purpose file? Is the support for actually compiling kernel
> source files from the arch/$(ARCH) Makefile eventually going away?
No, I do not think so.
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Best Regards
Masahiro Yamada
On Sat, Aug 31, 2019 at 10:04:53PM +0900, Masahiro Yamada wrote:
> Kbuild support two file names, "Makefile" and "Kbuild"
> for describing obj-y, obj-m, etc.
<snipping the basic explanation, which is documented pretty well,
I I think I full understand>
> Similarly, arch/$(SRCARCH)/Makefile is very special
> in that it is included from the top-level Makefile,
> and specify arch-specific compiler flags etc.
>
> We can use arch/$(SRCARCH)/Kbuild
> to specify obj-y, obj-m.
> The top-level Makefile does not need to know
> the directory structure under arch/$(SRCARCH)/.
>
> This is logical separation.
But only if we document this specific split and eventually stop allowing
to build objects from arch/$(SRCARCH)/Makefile. And in my perfect world
we'd eventually phase out the magic arch/$(SRCARCH)/Makefile entireŀy.
In addition to the normal Kbuild file we'd then have say (names entirely
made up and probably not the best idea)
arch/$(SRCARCH)/flags.mk to set the various compiler flags and co
arch/$(SRCARCH)/targets.mk for extra arch-specific targets
On Mon, Sep 2, 2019 at 4:42 PM Christoph Hellwig <[email protected]> wrote:
>
> On Sat, Aug 31, 2019 at 10:04:53PM +0900, Masahiro Yamada wrote:
> > Kbuild support two file names, "Makefile" and "Kbuild"
> > for describing obj-y, obj-m, etc.
>
> <snipping the basic explanation, which is documented pretty well,
> I I think I full understand>
>
> > Similarly, arch/$(SRCARCH)/Makefile is very special
> > in that it is included from the top-level Makefile,
> > and specify arch-specific compiler flags etc.
> >
> > We can use arch/$(SRCARCH)/Kbuild
> > to specify obj-y, obj-m.
> > The top-level Makefile does not need to know
> > the directory structure under arch/$(SRCARCH)/.
> >
> > This is logical separation.
>
> But only if we document this specific split and eventually stop allowing
> to build objects from arch/$(SRCARCH)/Makefile.
I like this idea, but it would change the link order (i.e. probe order)
For example, I want move all drivers-y in arch/x86/Makefile
to arch/x86/Kbuild.
I do not know how much we care about the probe order.
> And in my perfect world
> we'd eventually phase out the magic arch/$(SRCARCH)/Makefile entireŀy.
> In addition to the normal Kbuild file we'd then have say (names entirely
> made up and probably not the best idea)
>
> arch/$(SRCARCH)/flags.mk to set the various compiler flags and co
> arch/$(SRCARCH)/targets.mk for extra arch-specific targets
I am not sure whether this split is a good idea.
What is the problem with having the single arch-Makefile?
--
Best Regards
Masahiro Yamada