[PATCH 1/2] fs/efs/inode.c: follow style guide

[PATCH 1/2] fs/efs/inode.c: follow style guide

[Amy Parker]

This patch updates inode.c for EFS to follow the kernel style guide.

Signed-off-by: Amy Parker <enbyamy@gmail.com>
---
fs/efs/inode.c | 64 +++++++++++++++++++++++++-------------------------
1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/fs/efs/inode.c b/fs/efs/inode.c
index 89e73a6f0d36..4e81e7a15afb 100644
--- a/fs/efs/inode.c
+++ 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) {
               inode->i_blocks = 0;
-       } else {
+       else
               inode->i_blocks = ((inode->i_size - 1) >>
EFS_BLOCKSIZE_BITS) + 1;
-       }
+

       rdev = be16_to_cpu(efs_inode->di_u.di_dev.odev);
       if (rdev == 0xffff) {
@@ -120,15 +120,16 @@ struct inode *efs_iget(struct super_block
*super, unsigned long ino)
                       device = 0;
               else
                       device = MKDEV(sysv_major(rdev), sysv_minor(rdev));
-       } else
+       } else {
               device = old_decode_dev(rdev);
+    }

       /* get the number of extents for this object */
       in->numextents = be16_to_cpu(efs_inode->di_numextents);
       in->lastextent = 0;

       /* copy the extents contained within the inode to memory */
-       for(i = 0; i < EFS_DIRECTEXTENTS; i++) {
+       for (i = 0; i < EFS_DIRECTEXTENTS; i++) {
               extent_copy(&(efs_inode->di_u.di_extents[i]), &(in->extents[i]));
               if (i < in->numextents && in->extents[i].cooked.ex_magic != 0) {
                       pr_warn("extent %d has bad magic number in inode %lu\n",
@@ -142,28 +143,28 @@ struct inode *efs_iget(struct super_block
*super, unsigned long ino)
       pr_debug("efs_iget(): inode %lu, extents %d, mode %o\n",
                inode->i_ino, in->numextents, inode->i_mode);
       switch (inode->i_mode & S_IFMT) {
-               case S_IFDIR:
-                       inode->i_op = &efs_dir_inode_operations;
-                       inode->i_fop = &efs_dir_operations;
-                       break;
-               case S_IFREG:
-                       inode->i_fop = &generic_ro_fops;
-                       inode->i_data.a_ops = &efs_aops;
-                       break;
-               case S_IFLNK:
-                       inode->i_op = &page_symlink_inode_operations;
-                       inode_nohighmem(inode);
-                       inode->i_data.a_ops = &efs_symlink_aops;
-                       break;
-               case S_IFCHR:
-               case S_IFBLK:
-               case S_IFIFO:
-                       init_special_inode(inode, inode->i_mode, device);
-                       break;
-               default:
-                       pr_warn("unsupported inode mode %o\n", inode->i_mode);
-                       goto read_inode_error;
-                       break;
+    case S_IFDIR:
+        inode->i_op = &efs_dir_inode_operations;
+        inode->i_fop = &efs_dir_operations;
+        break;
+    case S_IFREG:
+        inode->i_fop = &generic_ro_fops;
+        inode->i_data.a_ops = &efs_aops;
+        break;
+    case S_IFLNK:
+        inode->i_op = &page_symlink_inode_operations;
+        inode_nohighmem(inode);
+        inode->i_data.a_ops = &efs_symlink_aops;
+        break;
+    case S_IFCHR:
+    case S_IFBLK:
+    case S_IFIFO:
+        init_special_inode(inode, inode->i_mode, device);
+        break;
+    default:
+        pr_warn("unsupported inode mode %o\n", inode->i_mode);
+        goto read_inode_error;
+        break;
       }

       unlock_new_inode(inode);
@@ -189,11 +190,10 @@ efs_extent_check(efs_extent *ptr, efs_block_t
block, struct efs_sb_info *
sb) {
       length = ptr->cooked.ex_length;
       offset = ptr->cooked.ex_offset;

-       if ((block >= offset) && (block < offset+length)) {
+       if ((block >= offset) && (block < offset+length))
               return(sb->fs_start + start + block - offset);
-       } else {
+       else
               return 0;
-       }
}

efs_block_t efs_map_block(struct inode *inode, efs_block_t block) {
@@ -225,7 +225,7 @@ efs_block_t efs_map_block(struct inode *inode,
efs_block_t block) {
                * check the stored extents in the inode
                * start with next extent and check forwards
                */
-               for(dirext = 1; dirext < direxts; dirext++) {
+               for (dirext = 1; dirext < direxts; dirext++) {
                       cur = (last + dirext) % in->numextents;
                       if ((result =
efs_extent_check(&in->extents[cur], block, sb))) {
                               in->lastextent = cur;
@@ -242,7 +242,7 @@ efs_block_t efs_map_block(struct inode *inode,
efs_block_t block) {
       direxts = in->extents[0].cooked.ex_offset;
       indexts = in->numextents;

-       for(indext = 0; indext < indexts; indext++) {
+       for (indext = 0; indext < indexts; indext++) {
               cur = (last + indext) % indexts;

               /*
@@ -253,7 +253,7 @@ efs_block_t efs_map_block(struct inode *inode,
efs_block_t block) {
                *
                */
               ibase = 0;
-               for(dirext = 0; cur < ibase && dirext < direxts; dirext++) {
+               for (dirext = 0; cur < ibase && dirext < direxts; dirext++) {
                       ibase += in->extents[dirext].cooked.ex_length *
                               (EFS_BLOCKSIZE / sizeof(efs_extent));
               }
--
2.29.2

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

[Randy Dunlap]

Hi Amy,

What mail client did you use?
It is breaking (splitting) long lines into shorter lines and that
makes it not possible to apply the patch cleanly.

You can see this problem below or on the web in an email archive.

Possibly Documentation/process/email-clients.rst can help you.


On 1/26/21 12:58 PM, Amy Parker wrote:
> This patch updates inode.c for EFS to follow the kernel style guide.
> 
> Signed-off-by: Amy Parker <enbyamy@gmail.com>
> ---
> fs/efs/inode.c | 64 +++++++++++++++++++++++++-------------------------
> 1 file changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/fs/efs/inode.c b/fs/efs/inode.c
> index 89e73a6f0d36..4e81e7a15afb 100644
> --- a/fs/efs/inode.c
> +++ 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) {
>                inode->i_blocks = 0;
> -       } else {
> +       else
>                inode->i_blocks = ((inode->i_size - 1) >>
> EFS_BLOCKSIZE_BITS) + 1;
> -       }
> +
> 
>        rdev = be16_to_cpu(efs_inode->di_u.di_dev.odev);
>        if (rdev == 0xffff) {
> @@ -120,15 +120,16 @@ struct inode *efs_iget(struct super_block
> *super, unsigned long ino)
>                        device = 0;
>                else
>                        device = MKDEV(sysv_major(rdev), sysv_minor(rdev));
> -       } else
> +       } else {
>                device = old_decode_dev(rdev);
> +    }
> 
>        /* get the number of extents for this object */
>        in->numextents = be16_to_cpu(efs_inode->di_numextents);
>        in->lastextent = 0;
> 
>        /* copy the extents contained within the inode to memory */
> -       for(i = 0; i < EFS_DIRECTEXTENTS; i++) {
> +       for (i = 0; i < EFS_DIRECTEXTENTS; i++) {
>                extent_copy(&(efs_inode->di_u.di_extents[i]), &(in->extents[i]));
>                if (i < in->numextents && in->extents[i].cooked.ex_magic != 0) {
>                        pr_warn("extent %d has bad magic number in inode %lu\n",
> @@ -142,28 +143,28 @@ struct inode *efs_iget(struct super_block
> *super, unsigned long ino)
>        pr_debug("efs_iget(): inode %lu, extents %d, mode %o\n",
>                 inode->i_ino, in->numextents, inode->i_mode);
>        switch (inode->i_mode & S_IFMT) {
> -               case S_IFDIR:
> -                       inode->i_op = &efs_dir_inode_operations;
> -                       inode->i_fop = &efs_dir_operations;
> -                       break;
> -               case S_IFREG:
> -                       inode->i_fop = &generic_ro_fops;
> -                       inode->i_data.a_ops = &efs_aops;
> -                       break;
> -               case S_IFLNK:
> -                       inode->i_op = &page_symlink_inode_operations;
> -                       inode_nohighmem(inode);
> -                       inode->i_data.a_ops = &efs_symlink_aops;
> -                       break;
> -               case S_IFCHR:
> -               case S_IFBLK:
> -               case S_IFIFO:
> -                       init_special_inode(inode, inode->i_mode, device);
> -                       break;
> -               default:
> -                       pr_warn("unsupported inode mode %o\n", inode->i_mode);
> -                       goto read_inode_error;
> -                       break;
> +    case S_IFDIR:
> +        inode->i_op = &efs_dir_inode_operations;
> +        inode->i_fop = &efs_dir_operations;
> +        break;
> +    case S_IFREG:
> +        inode->i_fop = &generic_ro_fops;
> +        inode->i_data.a_ops = &efs_aops;
> +        break;
> +    case S_IFLNK:
> +        inode->i_op = &page_symlink_inode_operations;
> +        inode_nohighmem(inode);
> +        inode->i_data.a_ops = &efs_symlink_aops;
> +        break;
> +    case S_IFCHR:
> +    case S_IFBLK:
> +    case S_IFIFO:
> +        init_special_inode(inode, inode->i_mode, device);
> +        break;
> +    default:
> +        pr_warn("unsupported inode mode %o\n", inode->i_mode);
> +        goto read_inode_error;
> +        break;
>        }
> 
>        unlock_new_inode(inode);
> @@ -189,11 +190,10 @@ efs_extent_check(efs_extent *ptr, efs_block_t
> block, struct efs_sb_info *
> sb) {
>        length = ptr->cooked.ex_length;
>        offset = ptr->cooked.ex_offset;
> 
> -       if ((block >= offset) && (block < offset+length)) {
> +       if ((block >= offset) && (block < offset+length))
>                return(sb->fs_start + start + block - offset);
> -       } else {
> +       else
>                return 0;
> -       }
> }
> 
> efs_block_t efs_map_block(struct inode *inode, efs_block_t block) {
> @@ -225,7 +225,7 @@ efs_block_t efs_map_block(struct inode *inode,
> efs_block_t block) {
>                 * check the stored extents in the inode
>                 * start with next extent and check forwards
>                 */
> -               for(dirext = 1; dirext < direxts; dirext++) {
> +               for (dirext = 1; dirext < direxts; dirext++) {
>                        cur = (last + dirext) % in->numextents;
>                        if ((result =
> efs_extent_check(&in->extents[cur], block, sb))) {
>                                in->lastextent = cur;
> @@ -242,7 +242,7 @@ efs_block_t efs_map_block(struct inode *inode,
> efs_block_t block) {
>        direxts = in->extents[0].cooked.ex_offset;
>        indexts = in->numextents;
> 
> -       for(indext = 0; indext < indexts; indext++) {
> +       for (indext = 0; indext < indexts; indext++) {
>                cur = (last + indext) % indexts;
> 
>                /*
> @@ -253,7 +253,7 @@ efs_block_t efs_map_block(struct inode *inode,
> efs_block_t block) {
>                 *
>                 */
>                ibase = 0;
> -               for(dirext = 0; cur < ibase && dirext < direxts; dirext++) {
> +               for (dirext = 0; cur < ibase && dirext < direxts; dirext++) {
>                        ibase += in->extents[dirext].cooked.ex_length *
>                                (EFS_BLOCKSIZE / sizeof(efs_extent));
>                }
> --
> 2.29.2
> 


-- 
~Randy
Reported-by: Randy Dunlap <rdunlap@infradead.org>
netiquette: https://people.kernel.org/tglx/notes-about-netiquette

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

[Randy Dunlap]

On 1/26/21 7:46 PM, Randy Dunlap wrote:
> Hi Amy,
> 
> What mail client did you use?
> It is breaking (splitting) long lines into shorter lines and that
> makes it not possible to apply the patch cleanly.
> 
> You can see this problem below or on the web in an email archive.
> 
> Possibly Documentation/process/email-clients.rst can help you.

Also tabs in the source file have been converted to spaces.

It would be good if you could email a patch to yourself and then
see if you can apply cleanly it to your source tree (after removing
any conflicting patches, of course -- or use a different source
tree).


-- 
~Randy
Reported-by: Randy Dunlap <rdunlap@infradead.org>
netiquette: https://people.kernel.org/tglx/notes-about-netiquette

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

[Amy Parker]

On Tue, Jan 26, 2021 at 7:59 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 1/26/21 7:46 PM, Randy Dunlap wrote:
> > Hi Amy,
> >
> > What mail client did you use?
> > It is breaking (splitting) long lines into shorter lines and that
> > makes it not possible to apply the patch cleanly.

Was worried about that, thought I had all my settings straightened out.

> >
> > You can see this problem below or on the web in an email archive.
> >
> > Possibly Documentation/process/email-clients.rst can help you.

Yeah, read that. Thought I had everything fixed up.

>
> Also tabs in the source file have been converted to spaces.

Was this inconsistent throughout the patch? I can't really seem to
tell. If it's consistent, bet it's probably my mail client - if it's
inconsistent it could be my editor, I had to switch out temporarily
for a different editor today.

>
> It would be good if you could email a patch to yourself and then
> see if you can apply cleanly it to your source tree (after removing
> any conflicting patches, of course -- or use a different source
> tree).

Yeah, I'll make sure to double check with that in the future.

>
>
> --
> ~Randy
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> netiquette: https://people.kernel.org/tglx/notes-about-netiquette

Should I send in a v2 of this patchset, or just attach the patch here?
If I should just attach it here, then I'll do the same for patch 2/2.

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

[Randy Dunlap]

On 1/26/21 9:13 PM, Amy Parker wrote:
> On Tue, Jan 26, 2021 at 7:59 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>> On 1/26/21 7:46 PM, Randy Dunlap wrote:
>>> Hi Amy,
>>>
>>> What mail client did you use?
>>> It is breaking (splitting) long lines into shorter lines and that
>>> makes it not possible to apply the patch cleanly.
> 
> Was worried about that, thought I had all my settings straightened out.
> 
>>>
>>> You can see this problem below or on the web in an email archive.
>>>
>>> Possibly Documentation/process/email-clients.rst can help you.
> 
> Yeah, read that. Thought I had everything fixed up.
> 
>>
>> Also tabs in the source file have been converted to spaces.
> 
> Was this inconsistent throughout the patch? I can't really seem to
> tell. If it's consistent, bet it's probably my mail client - if it's
> inconsistent it could be my editor, I had to switch out temporarily
> for a different editor today.
> 

There are no tabs in the patch.

>>
>> It would be good if you could email a patch to yourself and then
>> see if you can apply cleanly it to your source tree (after removing
>> any conflicting patches, of course -- or use a different source
>> tree).
> 
> Yeah, I'll make sure to double check with that in the future.
> 
>>
>>
>> --
>> ~Randy
>> Reported-by: Randy Dunlap <rdunlap@infradead.org>
>> netiquette: https://people.kernel.org/tglx/notes-about-netiquette
> 
> Should I send in a v2 of this patchset, or just attach the patch here?
> If I should just attach it here, then I'll do the same for patch 2/2.

An attachment might be OK once but it would be better if you
could get inline patches to work. You'll need to do that...


-- 
~Randy

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

[Kari Argillander]

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. 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 

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. 

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.

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

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

[Amy Parker]

On Wed, Jan 27, 2021 at 9:08 AM Kari Argillander
<kari.argillander@gmail.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)