Behaviour of kernel makefiles when entering a subdir using a config symbol = m

Behaviour of kernel makefiles when entering a subdir using a config symbol = m

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

Hi,

I wonder if this is as designed, or a bug:

I have a makefile which has

obj-$(CONFIG_FOO) += foo/

In the foo directory, I have a makefile which has

obj-$(CONFIG_FOO_BAR) += bar.o

The values of the variables are

CONFIG_FOO=m
CONFIG_FOO_BAR=y

When building the kernel with the above setup, I would expect make to
enter the foo/ directory, and build 'bar.o' into the kernel image.

And make does enter the directory, and does compile 'bar.o', but I think
'bar.o' doesn't end up anywhere. At least it's not compiled into the
kernel image.

If CONFIG_FOO=y, then 'bar.o' will be built in to the kernel image.

Am I doing something wrong here?

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Behaviour of kernel makefiles when entering a subdir using a config symbol = m

[Sam Ravnborg]

On Wed, Dec 09, 2015 at 08:25:08PM +0200, Tomi Valkeinen wrote:
> Hi,
> 
> I wonder if this is as designed, or a bug:
> 
> I have a makefile which has
> 
> obj-$(CONFIG_FOO) += foo/
> 
> In the foo directory, I have a makefile which has
> 
> obj-$(CONFIG_FOO_BAR) += bar.o
> 
> The values of the variables are
> 
> CONFIG_FOO=m
> CONFIG_FOO_BAR=y
> 
> When building the kernel with the above setup, I would expect make to
> enter the foo/ directory, and build 'bar.o' into the kernel image.
> 
> And make does enter the directory, and does compile 'bar.o', but I think
> 'bar.o' doesn't end up anywhere. At least it's not compiled into the
> kernel image.
kbuild may enter a sub directory for two purposes:
1) to build object files to be part of the final image
   Only subdirs specified using obj-y is visited.

2) to build object files that will be included in a module
   Subdirs specified with obj-y and obj-m is visited

Since you have the following code in your Makefile:

    obj-m += foo/

then foo/ is only visited to build modules.

So bar.o is built but is NOT included in the final image.
This is also the behaviour you see.

	Sam

Re: Behaviour of kernel makefiles when entering a subdir using a config symbol = m

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

Hi Sam,

On 09/12/15 23:32, Sam Ravnborg wrote:

> kbuild may enter a sub directory for two purposes:
> 1) to build object files to be part of the final image
>    Only subdirs specified using obj-y is visited.
> 
> 2) to build object files that will be included in a module
>    Subdirs specified with obj-y and obj-m is visited
> 
> Since you have the following code in your Makefile:
> 
>     obj-m += foo/
> 
> then foo/ is only visited to build modules.
> 
> So bar.o is built but is NOT included in the final image.
> This is also the behaviour you see.

Right.

We have three drivers (one fbdev, two drm), each of which can be built
as a module. But each of them also may require small boot-time setup,
which needs to be built-in.

I can get around the problem by entering the dir with obj-y, or by
creating a new extra config define which is y/n, and using that in the
makefile. The former makes make enter the dir even if the driver is not
enabled, and latter creates a config symbol only to solve this problem.

So I'd rather use the normal obj-$(CONFIG_MYDRIVER), as that's used by
all the fbdev and drm drivers, and (to me) makes most sense.

Is the purpose of the current behaviour to speed up the build when
compiling only the modules? Or why does it behave that way?

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Behaviour of kernel makefiles when entering a subdir using a config symbol = m

[Sam Ravnborg]

On Thu, Dec 10, 2015 at 09:44:45AM +0200, Tomi Valkeinen wrote:
> Hi Sam,
> 
> On 09/12/15 23:32, Sam Ravnborg wrote:
> 
> > kbuild may enter a sub directory for two purposes:
> > 1) to build object files to be part of the final image
> >    Only subdirs specified using obj-y is visited.
> > 
> > 2) to build object files that will be included in a module
> >    Subdirs specified with obj-y and obj-m is visited
> > 
> > Since you have the following code in your Makefile:
> > 
> >     obj-m += foo/
> > 
> > then foo/ is only visited to build modules.
> > 
> > So bar.o is built but is NOT included in the final image.
> > This is also the behaviour you see.
> 
> Right.
> 
> We have three drivers (one fbdev, two drm), each of which can be built
> as a module. But each of them also may require small boot-time setup,
> which needs to be built-in.
> 
> I can get around the problem by entering the dir with obj-y, or by
> creating a new extra config define which is y/n, and using that in the
> makefile. The former makes make enter the dir even if the driver is not
> enabled, and latter creates a config symbol only to solve this problem.
The extra config symbol is the most elegant solution here IMO.
Make sure to document that this config symbol enables the boot-time
setup stuff.

	Sam

Re: Behaviour of kernel makefiles when entering a subdir using a config symbol = m

[Michal Marek]

Dne 10.12.2015 v 21:46 Sam Ravnborg napsal(a):
> On Thu, Dec 10, 2015 at 09:44:45AM +0200, Tomi Valkeinen wrote:
>> We have three drivers (one fbdev, two drm), each of which can be built
>> as a module. But each of them also may require small boot-time setup,
>> which needs to be built-in.
>>
>> I can get around the problem by entering the dir with obj-y, or by
>> creating a new extra config define which is y/n, and using that in the
>> makefile. The former makes make enter the dir even if the driver is not
>> enabled, and latter creates a config symbol only to solve this problem.
> The extra config symbol is the most elegant solution here IMO.
> Make sure to document that this config symbol enables the boot-time
> setup stuff.

Agreed. We could tech kbuild to look for built-in.o also in obj-m
subdirs, but I'm quite sure it would break a Makefile or two. We had
this case when adding support for modname-m recently, a couple of
Makefiles did not expect this and broke.

Michal