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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 18 Dec 2018 12:09:56 +0200
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Marc Gonzalez <marc.w.gonzalez@...e.fr>
Cc:     Amit Kucheria <amit.kucheria@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        MSM <linux-arm-msm@...r.kernel.org>,
        Andy Gross <andy.gross@...aro.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "David S. Miller" <davem@...emloft.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v1 1/1] MAINTAINERS: update list of qcom drivers

Marc Gonzalez <marc.w.gonzalez@...e.fr> writes:

> On 18/12/2018 08:42, Kalle Valo wrote:
>
>> Amit Kucheria wrote:
>> 
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -1929,20 +1929,14 @@ M:	Andy Gross <andy.gross@...aro.org>
>>>  M:	David Brown <david.brown@...aro.org>
>>>  L:	linux-arm-msm@...r.kernel.org
>>>  S:	Maintained
>>> -F:	Documentation/devicetree/bindings/soc/qcom/
>>> -F:	arch/arm/boot/dts/qcom-*.dts
>>> -F:	arch/arm/boot/dts/qcom-*.dtsi
>>> -F:	arch/arm/mach-qcom/
>>> -F:	arch/arm64/boot/dts/qcom/*
>>> +N:	qcom
>>> +N:	msm
>> 
>> IMHO this is pretty fragile in the long term. For example only due to
>> historical reasons qualcomm wireless drivers currently under ath
>> directory but who knows if at some point we switch using qcom (or
>> qualcomm) directory.
>
> I am failing to follow your logic.
>
> (IIUC, you are talking about drivers/net/wireless/ath/ath10k)

Yeah, my example was just about ath10k and wil6210 as they go through my
tree. But it can apply to any other driver and subsystem as well:
bluetooth, future drivers and what ever works with Qualcomm hardware.

> The fact that the "qcom" or "msm" nomenclature is not used for this driver now
> just means that an explicit F entry is required. The fact that it could be renamed
> in the future just means that the entry would need to be updated or folded into a
> more generic matching pattern. What am I missing?

Not sure, but maybe you are missing the point that keeping MAINTAINER's
file up-to-date is hard and having uncommon rules like Amit and you
propose makes it even harder. Yeah, it should be simple but in practise
it's not, people easily forget to update it.

>> Also the wireless drivers might easily have filenames containing
>> strings like "msm" or "qcom" (which I assume would match with "N"
>> rules above).
>
> Any driver (not just wireless) might match "msm" or "qcom". These could be excluded
> with an X directive (as the proposed patch does, in fact).

Nobody will remember, or even know (for example I saw Amit's patch by
accident), that when adding files with string "qcom" or "msm" in path
you also need to add an exclusion to "ARM/QUALCOMM SUPPORT". That won't
work so errors are likely. It's a much safer approach to use F: rules
just like Joe proposed, that way the risk of people submitting patches
to wrong lists is reduced.

-- 
Kalle Valo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ