linux-kernel - Re: [PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdUdsH3r7AZMB6NfNyrDdJecXx1JhGZFA=32VYZBtmGP5w@mail.gmail.com>
Date:   Thu, 22 Mar 2018 16:13:13 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Frank.Rowand@...y.com, Arnd Bergmann <arnd@...db.de>,
        David Airlie <airlied@...ux.ie>,
        Niklas Söderlund 
        <niklas.soderlund+renesas@...natech.se>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Subject: Re: [PATCH] [RFC] drm: rcar-du: keep temporary dtb files around
 during build

Hi Laurent,

CC Yamada-san

On Thu, Mar 22, 2018 at 3:50 PM, Laurent Pinchart
<laurent.pinchart@...asonboard.com> wrote:
> On Thursday, 22 March 2018 16:26:22 EET Geert Uytterhoeven wrote:
>> On Fri, Mar 16, 2018 at 2:39 AM,  <Frank.Rowand@...y.com> wrote:
>> > On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann wrote:
>> >> The *.dtb and *.dtb.S files get removed by 'make' during the build
>> >> process, and later seem to be missed during the 'modpost' stage:
>> >>
>> >> rm drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb
>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb
>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb.S
>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb.S
>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S
>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb
>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb
>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb
>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb.S
>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb.S
>> >> WARNING: could not open
>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S: No such file or
>> >> directory
>> >>
>> >> As a workaround, this adds all those files to the 'extra-y' target list,
>> >> but that's really ugly. Any ideas for a better fix?
>> >
>> > Does this work for you (untested, but the way it is done in
>> > drivers/of/unittest-data/Makefile):
>> >
>> > .PRECIOUS: \
>> >
>> >         $(obj)/%.dtb.S \
>> >         $(obj)/%.dtb
>>
>> Shouldn't that just be moved to scripts/Makefile.lib, just above the rule
>> to make dtb.S, like is done for other precious objects?
>
> Without any implied acknowledgment that keeping those intermediate files is
> the right solution (I don't claim to master the kernel build system), I think

Me neither, but I think it is.

Cfr. .y => .tab.c => .tab.o with .tab.c marked PRECIOUS.

> such a rule would indeed be better in a core Makefile, as the rules to build
> the .dtb.o file comes from the core too. Could another option be to create a
> rule to compile a .dtb.o from the .dts file directly without going through
> intermediate files that will be removed automatically ?

Such a rules needs to execute two commands, which is more tricky, considering
error handling.
It's easier (to get right) to have two separate rules, and let make chain them
automatically.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds