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]
Date:   Thu, 21 Jan 2021 08:18:10 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     David Gibson <david@...son.dropbear.id.au>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        Frank Rowand <frowand.list@...il.com>,
        Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Bill Mills <bill.mills@...aro.org>,
        Anmar Oueja <anmar.oueja@...aro.org>
Subject: Re: [PATCH V5 3/5] scripts: dtc: Remove the unused fdtdump.c file

On Thu, Jan 21, 2021 at 12:43 AM David Gibson
<david@...son.dropbear.id.au> wrote:
>
> On Thu, Jan 21, 2021 at 09:47:57AM +0530, Viresh Kumar wrote:
> > On 21-01-21, 11:44, David Gibson wrote:
> > > On Wed, Jan 20, 2021 at 12:36:45PM +0530, Viresh Kumar wrote:
> > > > This was copied from external DTC repository long back and isn't used
> > > > anymore. Over that the dtc tool can be used to generate the dts source
> > > > back from the dtb. Remove the unused fdtdump.c file.
> > > >
> > > > Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> > >
> > > Doesn't this make updating the kernel dtc from upstream needlessly
> > > more difficult?
> >
> > Hmm, I am not sure I understand the concern well. The kernel keeps a
> > list of files[1] it needs to automatically copy (using a script) from
> > the upstream dtc repo and fdtdump.c was never part of that. Keeping it
> > there isn't going to make any difficulty I believe.
>
> Hm, ok.  Seems a bit clunky compared to embedding the whole directory,
> but whatever.

Either way, it's a list of what to keep or what to omit as we don't
want build files nor tests. If we were to take the whole thing, then
we should do a submodule, but so far no one wants submodules in the
kernel tree. There is a git subtree feature now that could do the same
thing as the script. But the script is good enough only needing small
tweaks occasionally, and anything else is work.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ