linux-kernel - Re: [PATCH] devicetree: Move include prefixes from arch to separate directory

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: <CAOesGMgYDq5Sdk6OaK-mTyfdNGwcbgOVeKbeMSCOmwqd9k8TGQ@mail.gmail.com>
Date:   Mon, 15 May 2017 08:27:54 -0700
From:   Olof Johansson <olof@...om.net>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Russell King - ARM Linux <linux@...linux.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Mark Rutland <mark.rutland@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Mikael Starvik <starvik@...s.com>,
        Jesper Nilsson <jesper.nilsson@...s.com>,
        James Hogan <james.hogan@...tec.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Frank Rowand <frowand.list@...il.com>,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH] devicetree: Move include prefixes from arch to separate directory

On Mon, May 15, 2017 at 7:47 AM, Rob Herring <robh+dt@...nel.org> wrote:
> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
> <linux@...linux.org.uk> wrote:
>> On Mon, May 15, 2017 at 08:01:07AM -0500, Rob Herring wrote:
>>> I'd prefer not to mix things in scripts/dtc that aren't the import of
>>> dtc (yes, we do have a few other things already, but they are at least
>>> scripts). Couldn't this go in include/dt-bindings/ instead?
>>
>> I don't think that works.
>>
>> The include path used is "include", which means that we force people
>> to use:
>>
>> #include <dt-bindings/foo.dtsi>
>
> No, I was thinking you'd add include/dt-bindings/include-prefix/ to
> the include path instead of scripts/dtc/include-prefix/. The only
> downside I can see is people could mistakenly do:
>
> #include <dt-bindings/include-prefix/$arch/foo.dtsi>

I considered that but thought it was a worse solution than the one I
ended up with. It's just confusing to have -I paths that enter an
include hierarchy at different levels like that.

Just see what already happened with the mistake on rockchip, where
Heiko accidentally included <include/dt-include/...> instead -- it'd
be nice to catch that when it happens through tools

>>
>> in their DT files.  This means that we'd need to populate $topdir/include
>> with per-architecture symlinks on top of the 26 or so directories already
>> there, so that:
>>
>> #include <arch/foo.dtsi>
>>
>> would work.  That's quite horrible, since $topdir/include is the main
>> include path for C headers.
>>
>> I guess we could have symlinks inside include/dt-bindings, but that
>> makes the includes:
>>
>> #include <dt-bindings/arch/foo.dtsi>
>>
>> but that's rather absurd because these _aren't_ dt-binding definitions.
>
> True, but the same can be said that "scripts/dtc" is not includes nor
> kernel build infrastructure.
>
>> Maybe what we should do is:
>>
>> mkdir include/dt
>> git mv include/dt-bindings include/dt
>> for arch in arch/*; do
>>   dts=$arch/boot/dts
>>   if [ -d $dts ]; then
>>      a=include/dt/$(basename $arch)
>>      ln -s $dts $a
>>      git add $a
>>   fi
>> done
>> ... fixup scripts/Makefile.lib ...
>> git commit
>
> That would just break every existing include in dts files.

It doesn't break dts includes if done together with a change in -I,
but it might break includes from the driver side (or needs another -I
there).

>
> Another idea. Could kbuild create all the symlinks at build time instead?

I considered that, but given that we're talking about a few soft links
that we need to find a good home for, it seemed like overkill that
adds magic to the build process. Having somehting that is easily
discovered when looking around the source tree is a lot better.

I looked around the tree for suitable homes for this directory of
links, and the least out-of-place I could find was under scripts/dtc.
You even have a script for uprevving the imported dtc sources, so it's
not like it's causing any problems from that point of view. But I do
agree that it's not ideal -- it was just the least bad option I could
find at the time. Better suggestions are welcome.

-Olof