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: <vsrsvmrkqnmxs3ncqv5m2gevzefiq55tr2iolxlmoehsvgcfkn@hyx37vax6r5e>
Date: Mon, 17 Jun 2024 14:55:22 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Jean Delvare <jdelvare@...e.de>, 
	Douglas Anderson <dianders@...omium.org>
Cc: dri-devel@...ts.freedesktop.org, LKML <linux-kernel@...r.kernel.org>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, 
	Daniel Vetter <daniel@...ll.ch>, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH RESEND] drm/display: Drop obsolete dependency on
 COMPILE_TEST

On Mon, Jun 17, 2024 at 01:23:48PM GMT, Jean Delvare wrote:
> Hi Dmitry,
> 
> Thanks for your feedback.
> 
> On Mon, 17 Jun 2024 12:57:19 +0300, Dmitry Baryshkov wrote:
> > On Mon, Jun 17, 2024 at 10:30:30AM GMT, Jean Delvare wrote:
> > > Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
> > > is possible to test-build any driver which depends on OF on any
> > > architecture by explicitly selecting OF. Therefore depending on
> > > COMPILE_TEST as an alternative is no longer needed.  
> > 
> > The goal of this clause is to allow build-testing the driver with OF
> > being disabled (meaning that some of OF functions are stubbed and some
> > might disappear). I don't see how user-selectable OF provides the same
> > result.
> 
> Historically, the goal of this clause *was* to allow build-testing the
> driver on architectures which did not support OF, and that did make
> sense back then. As I understand it, building the driver without OF
> support was never a goal per se (if it was, then the driver wouldn't be
> set to depend on OF in the first place).
> 
> Some of my other submissions include the following explanation which
> you might find useful (I ended up stripping it on resubmission after
> being told I was being too verbose, but maybe it was needed after all):
> 
> It is actually better to always build such drivers with OF enabled,
> so that the test builds are closer to how each driver will actually be
> built on its intended target. Building them without OF may not test
> much as the compiler will optimize out potentially large parts of the
> code. In the worst case, this could even pop false positive warnings.
> Dropping COMPILE_TEST here improves the quality of our testing and
> avoids wasting time on non-existent issues.

This doesn't seem to match the COMPILE_TEST usage that I observe in
other places. For example, we frequently use 'depends on ARCH_QCOM ||
COMPILE_TEST'. Which means that the driver itself doesn't make sense
without ARCH_QCOM, but we want for it to be tested on non-ARCH_QCOM
cases. I think the same logic applies to 'depends on OF ||
COMPILE_TEST' clauses. The driver (DP AUX bus) depends on OF to be fully
functional, but it should be compilable even without OF case.

I'll let Douglas (in cc) comment if my understanding is incorrect.

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ