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  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:   Sat, 21 Nov 2020 10:02:17 -0800
From:   Joe Perches <joe@...ches.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>,
        trix@...hat.com, clang-built-linux@...glegroups.com
Cc:     linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
        xen-devel@...ts.xenproject.org, tboot-devel@...ts.sourceforge.net,
        kvm@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-acpi@...r.kernel.org, devel@...ica.org,
        amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
        intel-gfx@...ts.freedesktop.org, netdev@...r.kernel.org,
        linux-media@...r.kernel.org, MPT-FusionLinux.pdl@...adcom.com,
        linux-scsi@...r.kernel.org, linux-wireless@...r.kernel.org,
        ibm-acpi-devel@...ts.sourceforge.net,
        platform-driver-x86@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-fbdev@...r.kernel.org,
        ecryptfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        cluster-devel@...hat.com, linux-mtd@...ts.infradead.org,
        keyrings@...r.kernel.org, netfilter-devel@...r.kernel.org,
        coreteam@...filter.org, alsa-devel@...a-project.org,
        bpf@...r.kernel.org, linux-bluetooth@...r.kernel.org,
        linux-nfs@...r.kernel.org, patches@...nsource.cirrus.com
Subject: Re: [RFC] MAINTAINERS tag for cleanup robot

On Sat, 2020-11-21 at 09:18 -0800, James Bottomley wrote:
> On Sat, 2020-11-21 at 08:50 -0800, trix@...hat.com wrote:
> > A difficult part of automating commits is composing the subsystem
> > preamble in the commit log.  For the ongoing effort of a fixer
> > producing one or two fixes a release the use of 'treewide:' does
> > not seem appropriate.
> > 
> > It would be better if the normal prefix was used.  Unfortunately
> > normal is not consistent across the tree.
> > 
> > 	D: Commit subsystem prefix
> > 
> > ex/ for FPGA DFL DRIVERS
> > 
> > 	D: fpga: dfl:
> 
> I've got to bet this is going to cause more issues than it solves. 
> SCSI uses scsi: <driver>: for drivers but not every driver has a
> MAINTAINERS entry.  We use either scsi: or scsi: core: for mid layer
> things, but we're not consistent.  Block uses blk-<something>: for all
> of it's stuff but almost no <somtehing>s have a MAINTAINERS entry.  So
> the next thing you're going to cause is an explosion of suggested
> MAINTAINERs entries.

As well as some changes require simultaneous changes across
multiple subsystems.

> Has anyone actually complained about treewide:?

It depends on what you mean by treewide:

If a treewide: patch is applied by some "higher level" maintainer,
then generally, no.

If the treewide patch is also cc'd to many individual maintainers,
then yes, many many times.

Mostly because patches cause what is in their view churn or that
changes are not specific to their subsystem grounds.

The treewide patch is sometimes dropped, sometimes broken up and
generally not completely applied.

What would be useful in many cases like this is for a pre and post
application of the treewide patch to be compiled and the object
code verified for lack of any logic change.

Unfortunately, gcc does not guarantee deterministic compilation so
this isn't feasible with at least gcc.  Does clang guarantee this?

I'm not sure it's possible:
https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html


Powered by blists - more mailing lists