unwanted built-ins

unwanted built-ins

[jrun]

hello,

why things under drivers/gpu/drm get built despite CONFIG_DRM not being set?

i'm cross compiling for armv7a and pass this as KCONFIG_ALLCONFIG to
allnoconfig:
https://gist.github.com/257/d69a5e95bd42cd7db5f1012703113fd1

if i take drm-y as an example; it seems to me that drm-y should only be built if
CONFIG_DRM=y|m according to this line in drivers/gpu/drm/Makefile:

obj-$(CONFIG_DRM)+= drm.o

final .config has this:

#
# Graphics support
#
# CONFIG_IMX_IPUV3_CORE is not set
# CONFIG_DRM is not set


thanks in advance for help
-- jrun

Re: unwanted built-ins

[Randy Dunlap]

On 11/11/20 8:31 AM, jrun wrote:
> hello,
> 
> why things under drivers/gpu/drm get built despite CONFIG_DRM not being set?
> 
> i'm cross compiling for armv7a and pass this as KCONFIG_ALLCONFIG to
> allnoconfig:
> https://gist.github.com/257/d69a5e95bd42cd7db5f1012703113fd1
> 
> if i take drm-y as an example; it seems to me that drm-y should only be built if
> CONFIG_DRM=y|m according to this line in drivers/gpu/drm/Makefile:
> 
> obj-$(CONFIG_DRM)+= drm.o
> 
> final .config has this:
> 
> #
> # Graphics support
> #
> # CONFIG_IMX_IPUV3_CORE is not set
> # CONFIG_DRM is not set
> 
> 
> thanks in advance for help
> -- jrun
> 

Hi,

Is this a speed of build issue?
Yes, make is descending into multiple directories that are not
strictly needed in this kernel config:

  AR      drivers/gpu/drm/arm/built-in.a
  AR      drivers/gpu/drm/rcar-du/built-in.a
  AR      drivers/gpu/drm/omapdrm/dss/built-in.a
  AR      drivers/gpu/drm/omapdrm/displays/built-in.a
  AR      drivers/gpu/drm/omapdrm/built-in.a
  AR      drivers/gpu/drm/tilcdc/built-in.a
  AR      drivers/gpu/drm/imx/built-in.a
  AR      drivers/gpu/drm/i2c/built-in.a
  AR      drivers/gpu/drm/panel/built-in.a
  AR      drivers/gpu/drm/bridge/analogix/built-in.a
  AR      drivers/gpu/drm/bridge/cadence/built-in.a
  AR      drivers/gpu/drm/bridge/synopsys/built-in.a
  AR      drivers/gpu/drm/bridge/built-in.a
  AR      drivers/gpu/drm/hisilicon/built-in.a
  AR      drivers/gpu/drm/tiny/built-in.a
  AR      drivers/gpu/drm/xlnx/built-in.a
  AR      drivers/gpu/drm/built-in.a

The built-in.a files that I see being built are all of size 8 bytes.

Also, since kconfig still applies normal dependency checks to whatever
is in the KCONFIG_ALLCONFIG file [1], I had to modify that file like this:
(note that BCM_63XX was misspelled)


 # CONFIG_VM_EVENT_COUNTERS is not set
 # CONFIG_COMPAT_BRK is not set
 # CONFIG_SLAB_MERGE_DEFAULT is not set
+CONFIG_MMU=y
+CONFIG_ARCH_MULTIPLATFORM=y
+# CONFIG_ARCH_MULTI_V5 is not set
+# CONFIG_ARCH_MULTI_V4_V5 is not set
+CONFIG_ARCH_MULTI_V7=y
+CONFIG_ARCH_MULTI_V6_V7=y
 CONFIG_ARCH_BCM=y
-CONFIG_ARCH_BCM63XX=y
+CONFIG_ARCH_BCM_63XX=y
 # CONFIG_ATAGS is not set
 # CONFIG_SUSPEND is not set
 # CONFIG_STACKPROTECTOR is not set

[1] from Documentation/kbuild/kconfig.rst:
This 'KCONFIG_ALLCONFIG' file is a config file which contains
(usually a subset of all) preset config symbols.  These variable
settings are still subject to normal dependency checks.


-- 
~Randy

Re: unwanted built-ins

[jrun]

On Wed, Nov 11, 2020 at 10:09:18AM -0800, Randy Dunlap wrote:
> Hi,
> 
> Is this a speed of build issue?

i wasn't thinking about that but sure it does have that effect too.

> Yes, make is descending into multiple directories that are not
> strictly needed in this kernel config:
> 
>   AR      drivers/gpu/drm/arm/built-in.a
>   AR      drivers/gpu/drm/rcar-du/built-in.a
>   AR      drivers/gpu/drm/omapdrm/dss/built-in.a
>   AR      drivers/gpu/drm/omapdrm/displays/built-in.a
>   AR      drivers/gpu/drm/omapdrm/built-in.a
>   AR      drivers/gpu/drm/tilcdc/built-in.a
>   AR      drivers/gpu/drm/imx/built-in.a
>   AR      drivers/gpu/drm/i2c/built-in.a
>   AR      drivers/gpu/drm/panel/built-in.a
>   AR      drivers/gpu/drm/bridge/analogix/built-in.a
>   AR      drivers/gpu/drm/bridge/cadence/built-in.a
>   AR      drivers/gpu/drm/bridge/synopsys/built-in.a
>   AR      drivers/gpu/drm/bridge/built-in.a
>   AR      drivers/gpu/drm/hisilicon/built-in.a
>   AR      drivers/gpu/drm/tiny/built-in.a
>   AR      drivers/gpu/drm/xlnx/built-in.a
>   AR      drivers/gpu/drm/built-in.a
> 
> The built-in.a files that I see being built are all of size 8 bytes.

and they don't make it into the final image which is what i wanted. thanks.

now i would interested to know why some subsystems have those obj-y's
unconditionally asserted?
for instance, would something like this make sense?

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index df7650adede9..47508d8049d9 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -7,7 +7,7 @@ obj-$(CONFIG_FB_STI)		  += console/
 obj-$(CONFIG_LOGO)		  += logo/
 obj-y				  += backlight/

-obj-y				  += fbdev/
+obj-$(CONFIG_FB)		  += fbdev/

 obj-$(CONFIG_VIDEOMODE_HELPERS) += display_timing.o videomode.o
 ifeq ($(CONFIG_OF),y)

or this:

diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index 835c88318cec..c1a71f4938bb 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -3,6 +3,7 @@
 # taken to initialize them in the correct order. Link order is the only way
 # to ensure this currently.
 obj-$(CONFIG_TEGRA_HOST1X)	+= host1x/
-obj-y			+= drm/ vga/
+obj-y				+= vga/
+obj-$(CONFIG_DRM)		+= drm/
 obj-$(CONFIG_IMX_IPUV3_CORE)	+= ipu-v3/
 obj-$(CONFIG_TRACE_GPU_MEM)		+= trace/


- jrun

Re: unwanted built-ins

[Randy Dunlap]

On 11/11/20 11:00 AM, jrun wrote:
> On Wed, Nov 11, 2020 at 10:09:18AM -0800, Randy Dunlap wrote:
>> Hi,
>>
>> Is this a speed of build issue?
> 
> i wasn't thinking about that but sure it does have that effect too.
> 
>> Yes, make is descending into multiple directories that are not
>> strictly needed in this kernel config:
>>
>>   AR      drivers/gpu/drm/arm/built-in.a
>>   AR      drivers/gpu/drm/rcar-du/built-in.a
>>   AR      drivers/gpu/drm/omapdrm/dss/built-in.a
>>   AR      drivers/gpu/drm/omapdrm/displays/built-in.a
>>   AR      drivers/gpu/drm/omapdrm/built-in.a
>>   AR      drivers/gpu/drm/tilcdc/built-in.a
>>   AR      drivers/gpu/drm/imx/built-in.a
>>   AR      drivers/gpu/drm/i2c/built-in.a
>>   AR      drivers/gpu/drm/panel/built-in.a
>>   AR      drivers/gpu/drm/bridge/analogix/built-in.a
>>   AR      drivers/gpu/drm/bridge/cadence/built-in.a
>>   AR      drivers/gpu/drm/bridge/synopsys/built-in.a
>>   AR      drivers/gpu/drm/bridge/built-in.a
>>   AR      drivers/gpu/drm/hisilicon/built-in.a
>>   AR      drivers/gpu/drm/tiny/built-in.a
>>   AR      drivers/gpu/drm/xlnx/built-in.a
>>   AR      drivers/gpu/drm/built-in.a
>>
>> The built-in.a files that I see being built are all of size 8 bytes.
> 
> and they don't make it into the final image which is what i wanted. thanks.
> 
> now i would interested to know why some subsystems have those obj-y's
> unconditionally asserted?
> for instance, would something like this make sense?
> 
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index df7650adede9..47508d8049d9 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -7,7 +7,7 @@ obj-$(CONFIG_FB_STI)		  += console/
>  obj-$(CONFIG_LOGO)		  += logo/
>  obj-y				  += backlight/
> 
> -obj-y				  += fbdev/
> +obj-$(CONFIG_FB)		  += fbdev/
> 
>  obj-$(CONFIG_VIDEOMODE_HELPERS) += display_timing.o videomode.o
>  ifeq ($(CONFIG_OF),y)
> 
> or this:
> 
> diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
> index 835c88318cec..c1a71f4938bb 100644
> --- a/drivers/gpu/Makefile
> +++ b/drivers/gpu/Makefile
> @@ -3,6 +3,7 @@
>  # taken to initialize them in the correct order. Link order is the only way
>  # to ensure this currently.
>  obj-$(CONFIG_TEGRA_HOST1X)	+= host1x/
> -obj-y			+= drm/ vga/
> +obj-y				+= vga/
> +obj-$(CONFIG_DRM)		+= drm/
>  obj-$(CONFIG_IMX_IPUV3_CORE)	+= ipu-v3/
>  obj-$(CONFIG_TRACE_GPU_MEM)		+= trace/

Yeah, that may be the right thing to do, but it would take
a lot of build testing. My laptops don't have enough horsepower
for all of that (multiple configs * multiple arch-es).

-- 
~Randy

Re: unwanted built-ins

[jrun]

On Wed, Nov 11, 2020 at 07:14:52PM -0800, Randy Dunlap wrote:
> Yeah, that may be the right thing to do, but it would take
> a lot of build testing. My laptops don't have enough horsepower
> for all of that (multiple configs * multiple arch-es).
>
> --
> ~Randy
>

me no horsepower too but who does? i mean i could slam together couple of low
hanging candidates like those in a patch and submit (where? e.g. linux-drm?)
but, do you think it's worth the effort?

- jrun

Re: unwanted built-ins

[Randy Dunlap]

On 11/12/20 10:46 AM, jrun wrote:
> On Wed, Nov 11, 2020 at 07:14:52PM -0800, Randy Dunlap wrote:
>> Yeah, that may be the right thing to do, but it would take
>> a lot of build testing. My laptops don't have enough horsepower
>> for all of that (multiple configs * multiple arch-es).
>>
>> --
>> ~Randy
>>
> 
> me no horsepower too but who does? i mean i could slam together couple of low
> hanging candidates like those in a patch and submit (where? e.g. linux-drm?)
> but, do you think it's worth the effort?


It wouldn't take much effort to create such patches.
The effort would probably be more in justifying them and then
getting maintainers to merge them. Then they would go into the
linux-next tree(s) and hundreds (or more) people could test them,
along with several bots.

Unless the kernel build maintainer would put them into the
linux-kbuild tree for linux-next testing.  :)



BTW, reply-to-all is appropriate/common for Linux development,
not just reply-to-list.

thanks.
-- 
~Randy