linux-kernel - Re: [PATCH 1/2] fs/efs/inode.c: follow style guide

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]

Date:   Wed, 27 Jan 2021 09:25:11 -0800
From:   Amy Parker <enbyamy@...il.com>
To:     Kari Argillander <kari.argillander@...il.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] fs/efs/inode.c: follow style guide

On Wed, Jan 27, 2021 at 9:08 AM Kari Argillander
<kari.argillander@...il.com> wrote:
>
> On Tue, Jan 26, 2021 at 12:58:05PM -0800, Amy Parker wrote:
> > This patch updates inode.c for EFS to follow the kernel style guide.
>
> > +++ b/fs/efs/inode.c
> > @@ -109,9 +109,9 @@ struct inode *efs_iget(struct super_block *super,
> > unsigned long ino)
> >        /* this is the number of blocks in the file */
> >        if (inode->i_size == 0) {
>
> Still has { here so you didn't even compile this? Also I think you
> should make one patch for whole EFS.

I might've accidentally done that after the compile but before the commit.

> Just change one type of thing at
> ones. Like
>
> [Patch 1/X] fs/efs: Remove braces from single statments
> [Patch 2/X] fs/efs: Add space after C keywords
> [Patch 3/X] fs/efs: Fix code indent levels

Yeah, that's probably a better idea.

>
> That way it is super easy to review them. Also because there is no
> maintainer it is kind of scary to accept patches. Specially when lot of
> different kind of things are changed.

Ah yep, so having them organized would definitely be better.

>
> Please also send your patches against cover letter. If you have problem
> with your email client plese take a look git send-email. This will work
> beautiful for all of this.

Gonna being switching email services soon anyways, I'll be using git
send-email once I do.

>
> And because you are new (i think). Welcome.

Thank you!

Best regards,
Amy Parker
(she/her)