| Message ID | 20190821092658.32764-1-yamada.masahiro@socionext.com |
|---|---|
| State | Accepted |
| Commit | 909548d6c5789dbd6cd4c7a6b32fcf0ae974f5ee |
| Headers | show |
| Series | riscv: add arch/riscv/Kbuild | expand |
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.
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? -- 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 <yamada.masahiro@socionext.com> Thanks, queued for v5.4-rc1. - Paul
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 -- 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 <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? -- Best Regards Masahiro Yamada
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/
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 -- 2.17.1