* [PATCH 1/2] fs/efs/inode.c: follow style guide
@ 2021-01-26 20:58 Amy Parker
2021-01-27 3:46 ` Randy Dunlap
2021-01-27 17:08 ` Kari Argillander
0 siblings, 2 replies; 7+ messages in thread
From: Amy Parker @ 2021-01-26 20:58 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel
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
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH 1/2] fs/efs/inode.c: follow style guide
2021-01-26 20:58 [PATCH 1/2] fs/efs/inode.c: follow style guide Amy Parker
@ 2021-01-27 3:46 ` Randy Dunlap
2021-01-27 3:59 ` Randy Dunlap
2021-01-27 17:08 ` Kari Argillander
1 sibling, 1 reply; 7+ messages in thread
From: Randy Dunlap @ 2021-01-27 3:46 UTC (permalink / raw)
To: Amy Parker, linux-fsdevel, linux-kernel
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 1/2] fs/efs/inode.c: follow style guide
2021-01-27 3:46 ` Randy Dunlap
@ 2021-01-27 3:59 ` Randy Dunlap
2021-01-27 5:13 ` Amy Parker
0 siblings, 1 reply; 7+ messages in thread
From: Randy Dunlap @ 2021-01-27 3:59 UTC (permalink / raw)
To: Amy Parker, linux-fsdevel, linux-kernel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] fs/efs/inode.c: follow style guide
2021-01-27 3:59 ` Randy Dunlap
@ 2021-01-27 5:13 ` Amy Parker
2021-01-27 6:35 ` Randy Dunlap
0 siblings, 1 reply; 7+ messages in thread
From: Amy Parker @ 2021-01-27 5:13 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-fsdevel, linux-kernel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] fs/efs/inode.c: follow style guide
2021-01-27 5:13 ` Amy Parker
@ 2021-01-27 6:35 ` Randy Dunlap
0 siblings, 0 replies; 7+ messages in thread
From: Randy Dunlap @ 2021-01-27 6:35 UTC (permalink / raw)
To: Amy Parker; +Cc: linux-fsdevel, linux-kernel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] fs/efs/inode.c: follow style guide
2021-01-26 20:58 [PATCH 1/2] fs/efs/inode.c: follow style guide Amy Parker
2021-01-27 3:46 ` Randy Dunlap
@ 2021-01-27 17:08 ` Kari Argillander
2021-01-27 17:25 ` Amy Parker
1 sibling, 1 reply; 7+ messages in thread
From: Kari Argillander @ 2021-01-27 17:08 UTC (permalink / raw)
To: Amy Parker; +Cc: linux-fsdevel, linux-kernel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 1/2] fs/efs/inode.c: follow style guide
2021-01-27 17:08 ` Kari Argillander
@ 2021-01-27 17:25 ` Amy Parker
0 siblings, 0 replies; 7+ messages in thread
From: Amy Parker @ 2021-01-27 17:25 UTC (permalink / raw)
To: Kari Argillander; +Cc: linux-fsdevel, linux-kernel
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)
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-01-27 17:26 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-26 20:58 [PATCH 1/2] fs/efs/inode.c: follow style guide Amy Parker
2021-01-27 3:46 ` Randy Dunlap
2021-01-27 3:59 ` Randy Dunlap
2021-01-27 5:13 ` Amy Parker
2021-01-27 6:35 ` Randy Dunlap
2021-01-27 17:08 ` Kari Argillander
2021-01-27 17:25 ` Amy Parker
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.