diff mbox series

riscv: add arch/riscv/Kbuild

Message ID 20190821092658.32764-1-yamada.masahiro@socionext.com (mailing list archive)
State New, archived
Headers show
Series riscv: add arch/riscv/Kbuild | expand

Commit Message

Masahiro Yamada Aug. 21, 2019, 9:26 a.m. UTC
Use the standard obj-y form to specify the sub-directories under
arch/riscv/. No functional change intended.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/riscv/Kbuild   | 3 +++
 arch/riscv/Makefile | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)
 create mode 100644 arch/riscv/Kbuild

Comments

Christoph Hellwig Aug. 26, 2019, 11:35 a.m. UTC | #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 <yamada.masahiro@socionext.com>

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.
Masahiro Yamada Aug. 27, 2019, 5:14 a.m. UTC | #2
On Mon, Aug 26, 2019 at 8:35 PM Christoph Hellwig <hch@infradead.org> 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 <yamada.masahiro@socionext.com>
>
> 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?
Christoph Hellwig Aug. 30, 2019, 3:53 p.m. UTC | #3
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?
Paul Walmsley Aug. 31, 2019, 12:51 a.m. UTC | #4
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 <yamada.masahiro@socionext.com>

Thanks, queued for v5.4-rc1.


- Paul
Masahiro Yamada Aug. 31, 2019, 1:04 p.m. UTC | #5
On Sat, Aug 31, 2019 at 12:53 AM Christoph Hellwig <hch@infradead.org> 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
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Christoph Hellwig Sept. 2, 2019, 7:42 a.m. UTC | #6
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
Masahiro Yamada Sept. 3, 2019, 2:31 p.m. UTC | #7
On Mon, Sep 2, 2019 at 4:42 PM Christoph Hellwig <hch@infradead.org> 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?
diff mbox series

Patch

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/