linux-kernel - Re: [PATCH v2 PING] kallsyms: new /proc/kallmodsyms with builtin modules and symbol sizes

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: <YOa57bMUbUlxJ5Mv@p200300cbcf044300404ca642de146c7c.dip0.t-ipconnect.de>
Date:   Thu, 8 Jul 2021 10:40:13 +0200
From:   Jessica Yu <jeyu@...nel.org>
To:     Nick Alcock <nick.alcock@...cle.com>
Cc:     masahiroy@...nel.org, linux-modules@...r.kernel.org,
        linux-kernel@...r.kernel.org, arnd@...db.de,
        Eugene Loh <eugene.loh@...cle.com>,
        Kris Van Hees <kris.van.hees@...cle.com>
Subject: Re: [PATCH v2 PING] kallsyms: new /proc/kallmodsyms with builtin
 modules and symbol sizes

+++ Nick Alcock [07/07/21 20:07 +0100]:
>On 7 Jul 2021, Jessica Yu uttered the following:
>
>> +++ Nick Alcock [06/07/21 20:33 +0100]:
>>> 15 files changed, 1309 insertions(+), 67 deletions(-)
>>
>> This diffstat is seriously _enormous_. Please don't send patches of
>> this size and expect people to be willing to review :-(. Please break
>> this up into a logical sequence of smaller patches to help your
>> potential reviewers and resend with a cover letter.
>
>Heh, this is very project-dependent it seems. I've been told not to
>split up things so finely when sending series containing 3000+-line
>commits to various toolchain projects before :)

Huh, that's interesting :) 

>Since you are in the "slice finely" camp, I'll split it up a bunch and
>resend. (This will necessarily involve adding things in one commit to
>no obvious purpose in that commit, but I'll keep the intermediate stages
>building and booting, of course.)

Yes, the norm in the Linux kernel community is to split up large
patches into a logical sequence of smaller patches, this will help
reviewers a lot. Thanks in advance!