linux-kernel - Re: [RFC PATCH 1/3] ASoC: Add platforms directory

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] [day] [month] [year] [list]

Message-ID: <5aaa3cdc-613d-25fe-0149-db91f0b9d8c6@ti.com>
Date:   Wed, 6 Dec 2017 14:59:14 -0600
From:   "Andrew F. Davis" <afd@...com>
To:     Mark Brown <broonie@...nel.org>
CC:     Liam Girdwood <lgirdwood@...il.com>, <alsa-devel@...a-project.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/3] ASoC: Add platforms directory

On 12/06/2017 01:27 PM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 12:49:39PM -0600, Andrew F. Davis wrote:
>> On 12/06/2017 12:42 PM, Mark Brown wrote:
> 
>>> We need to preserve old bindings to ensure DT compatiblity, the easiest
>>> way to do that is to keep old machine drivers around.  There are plenty
>>> of older drivers that wouldn't be accepted now but would at least need
>>> replacing with a compatibility layer that adapts the bindings onto one
>>> of the generic drivers.  That adaption layer would definitely be useful
>>> (basically a big table of platform data) but it'd take time to implement
>>> it.
> 
>> We then should at least start depreciating them now so that someday we
>> can drop that stuff. Isolating them would be the first step.
> 
> Moving the drivers around is not going to help with that.  For users the
> drivers are not deprecated until someone actually steps up and makes
> something that allows the generic drivers to handle the old bindings and
> moves them over, at which point we'd just remove things that have been
> converted.  We can't just tell them not to use something without
> providing an alternative.  For developers they're just going to end up
> with the simpler machine drivers sitting next to a bunch of machine
> drivers that reasonably exist which I'm not sure clarifies anything.
> It's an orthogonal problem.
> 

It helps in that people would see an organized set of drivers to target,
"this folder here (sound/soc/machines/) should be reduced as much as
possible". Otherwise it is just, "go dig around for the machine drivers
burred together with platform drivers, which file is which type? Who
knows!?"

I will help too, but there needs to be just a bit of organization first.

>>> Wouldn't a few regexps in the MAINTAINERS file cover it?  We've already
>>> got a bunch of vendors doing this.
> 
>> pcm*
>> tas*
>> tlv*
>> twl*
> 
>> It's messy how many prefixes we have :/
> 
> Eh, not that bad.  And easy enough to do anyway.
> 

And it is easy enough to group them into a directory by something like
vendor, same as everyone else, including your very own sound/soc/. Yet
codecs/ is a giant 400+ file blob, by C file count it is the largest
directory in the whole kernel...

Top 10:

C files count: folder

130: drivers/staging/comedi/drivers
145: drivers/gpio
159: drivers/watchdog
164: drivers/rtc
165: drivers/hwmon
172: net/netfilter
175: drivers/acpi/acpica
194: lib
201: drivers/mfd
239: sound/soc/codecs

Maybe a bit of grouping wouldn't be so bad