netdev - Re: [PATCH 00/22] Replace comments with C99 initializers

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: <87bkxqz2b1.fsf@kernel.org>
Date:   Mon, 28 Mar 2022 15:31:14 +0300
From:   Kalle Valo <kvalo@...nel.org>
To:     Benjamin Stürz <benni@...erz.xyz>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org, linux-ia64@...r.kernel.org,
        linux-acpi@...r.kernel.org, devel@...ica.org,
        linux-atm-general@...ts.sourceforge.net, netdev@...r.kernel.org,
        linux-edac@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-rdma@...r.kernel.org, linux-input@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, linux-media@...r.kernel.org,
        wcn36xx@...ts.infradead.org, linux-wireless@...r.kernel.org,
        linux-pci@...r.kernel.org
Subject: Re: [PATCH 00/22] Replace comments with C99 initializers

Benjamin Stürz <benni@...erz.xyz> writes:

> On 28.03.22 11:33, Kalle Valo wrote:
>> Benjamin Stürz <benni@...erz.xyz> writes:
>> 
>>> This patch series replaces comments with C99's designated initializers
>>> in a few places. It also adds some enum initializers. This is my first
>>> time contributing to the Linux kernel, therefore I'm probably doing a
>>> lot of things the wrong way. I'm sorry for that.
>> 
>> Just a small tip: If you are new, start with something small and learn
>> from that. Don't do a controversial big patchset spanning multiple
>> subsystems, that's the hard way to learn things. First submit one patch
>> at a time to one subsystem and gain understanding of the process that
>> way.
>
> I actually thought this would be such simple thing.

If there are 22 patches and a dozen different subsystems it's far from
simple, as you noticed from your replies :)

> Do you know of any good thing where to start? I already looked into
> drivers/staging/*/TODO and didn't found something for me personally.

I work in wireless and one my annoyance is use of BUG_ON() in wireless
drivers. There just isn't a good reason to crash the whole system when
there's a bug in a wireless driver or firmware. You can get list like
this:

git grep BUG_ON drivers/net/wireless/ | grep -v BUILD_BUG_ON

It might not be always trivial to fix BUG_ON() usage, so it would be a
good challenge as well. See the wiki link below how to submit wireless
patches. But just send a one patch first, don't work for several hours
and then submit a big set of patches.

We also might have a todo list somewhere in the wiki, but don't know how
to up-to-date it is.

> Should I drop this patchset and start with something different? 

Like Mauro suggested, splitting the patchset per subsystem is a very
good idea. And first try out with one subsystem, and after seeing how it
goes (if they are accepted or rejected), decide if you send more patches
to other subsystems.

> If yes, what would the proper way to drop it? Just announcing, that
> this is going nowhere in a separate patch?

Replying to Mauro's email and telling your intentions is a good way to
inform everyone.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches