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:   Tue, 12 Jan 2021 14:07:03 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Bill Mills <bill.mills@...aro.org>
Cc:     Frank Rowand <frowand.list@...il.com>,
        Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        anmar.oueja@...aro.org, Masahiro Yamada <masahiroy@...nel.org>
Subject: Re: [PATCH] of: unittest: Statically apply overlays using fdtoverlay

On 11-01-21, 20:22, Bill Mills wrote:
> On 1/11/21 5:06 PM, Frank Rowand wrote:
> > NACK to this specific patch, in its current form.
> > 
> > There are restrictions on applying an overlay at runtime that do not apply
> > to applying an overlay to an FDT that will be loaded by the kernel during
> > early boot.  Thus the unittest overlays _must_ be applied using the kernel
> > overlay loading methods to test the kernel runtime overlay loading feature.
> > 
> > I agree that testing fdtoverlay is a good idea.  I have not looked at the
> > parent project to see how much testing of fdtoverlay occurs there, but I
> > would prefer that fdtoverlay tests reside in the parent project if practical
> > and reasonable.  If there is some reason that some fdtoverlay tests are
> > more practical in the Linux kernel repository then I am open to adding
> > them to the Linux kernel tree.

I wasn't looking to add any testing for fdtoverlay in the kernel, but
then I stumbled upon unit-tests here and thought it would be a good
idea to get this built using static tools as well, as we aren't
required to add any new source files for this and the existing tests
already cover a lot of nodes.

And so I am fine if we don't want to do this stuff in kernel.

> I thought we were aligned that any new overlays into the kernel today would
> only be for boot loader applied case.  Applying overlays at kernel runtime
> was out of scope at your request.
> 
> Rob had requested that the overlays be test applied at build time.  I don't
> think there is any way to test the kernel runtime method at build time
> correct?
> 
> Please clarify your concern and your suggested way forward.

The kernel does some overlay testing currently (at kernel boot only,
not later), to see if the overlays get applied correctly or not, these
are the unit tests.

What Frank is probably saying is that the unit-tests dtbs shouldn't
get used for testing fdtoverlay stuff. He isn't asking to support
runtime application of overlays, but to not do fdtoverlay testing in
the kernel.

-- 
viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ