RE: CHECK: Alignment should match open parenthesis
-Original Message- From: Nicholas Mc Guire [mailto:der.h...@hofr.at] Sent: Friday, March 13, 2015 10:31 AM To: Jeff Haran Cc: Daniel Baluta; kernelnewbies@kernelnewbies.org; palik imre Subject: Re: CHECK: Alignment should match open parenthesis On Fri, 13 Mar 2015, Jeff Haran wrote: -Original Message- From: Nicholas Mc Guire [mailto:der.h...@hofr.at] Sent: Friday, March 13, 2015 9:59 AM To: Jeff Haran Cc: Daniel Baluta; kernelnewbies@kernelnewbies.org; palik imre Subject: Re: CHECK: Alignment should match open parenthesis On Fri, 13 Mar 2015, Jeff Haran wrote: -Original Message- From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Nicholas Mc Guire Sent: Friday, March 13, 2015 8:33 AM To: Daniel Baluta Cc: kernelnewbies@kernelnewbies.org; palik imre Subject: Re: CHECK: Alignment should match open parenthesis On Fri, 13 Mar 2015, Daniel Baluta wrote: On Fri, Mar 13, 2015 at 3:47 PM, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, Nicholas Mc Guire wrote: On Fri, 13 Mar 2015, palik imre wrote: On Friday, 13 March 2015, 13:43, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, palik imre wrote: Sorry for the silly question, but I have some issues with this checkpatch.pl warning. I mean Documentation/CodingStyle says: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. But checkpatch.pl claims I should align to open parentheses. These two things seem to be contradictory to me. Could somebody clarify this? leading tabs *followed* by spaces to align parameters to a function are fine The emacs settings in Documentation/CodingStyle seem to contradict to you, as it is set up to use c-lineup-arglist-tabs-only The problem is that CodingStyle does not explicitly address parameter alignment for functions that do not fit on a single line but checkpatch.pl does you can try it out - if you align to the opening braces with spaces with preceding TABs it will not fuss and this is also common practice. here is a quick shot at summarizing this If the parameter list to a functions would exceed the 80 char limit then break it at the separators, and align to opening braces, e.g.: ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout); or: int = wait_for_completion_interruptible_timeout(data-completion, PMI_TIMEOUT); Note that this is indented by tabs and then aligned with spaced to fit the opening braces. If you can not fit it even if you break the parameter list at the commas then indent by tabs only but *significantly* to the left of the opening braces, e.g.: int ret = wait_for_completion_interruptible_timeout( info-done, usecs_to_jiffies(TIMEOUT_US)); would be suprised if there is no writeup somewhere alredy but I did not find this covered in Documentations anywhere. I think it would be a coding idea to have this in CodingStyle doc :). At this level of detail it would be almost unmaintainable and also you would end up with far too many rules to actually keep them in mind. That is the job of tools like checkpatch.pl they can have all the myriads of corner cases encoded without creating a burden to the developers/maintainers. thx! hofrat I often see people writing posts to this list stating that they are want to get started and want to contribute something. I suppose this thread provides a suggestion for them. Take the latest version of checkpatch .pl and reverse engineer from it an update to the coding style document that documents in plain, human readable English what that script implements. Seems it bit back asswards to me for the requirements to derive from a script that implements them, but that seems to be where we are at. The very fact that this thread even exists, that the original question needed to be asked demonstrates that there's something missing in the style document. If you look at things like MISRA-C - 200+ Rules to follow for safe code it turns out that basically nobody is able to write MISRA compliant code under consideration of all 200+ rules unless they have tools that tell them what is wrong with enough information that it can be fixed. And at the same time having those rules codified makes it hard (if not impossible) to update/maintain these
Re: CHECK: Alignment should match open parenthesis
On Fri, 13 Mar 2015, Jeff Haran wrote: -Original Message- From: Nicholas Mc Guire [mailto:der.h...@hofr.at] Sent: Friday, March 13, 2015 9:59 AM To: Jeff Haran Cc: Daniel Baluta; kernelnewbies@kernelnewbies.org; palik imre Subject: Re: CHECK: Alignment should match open parenthesis On Fri, 13 Mar 2015, Jeff Haran wrote: -Original Message- From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Nicholas Mc Guire Sent: Friday, March 13, 2015 8:33 AM To: Daniel Baluta Cc: kernelnewbies@kernelnewbies.org; palik imre Subject: Re: CHECK: Alignment should match open parenthesis On Fri, 13 Mar 2015, Daniel Baluta wrote: On Fri, Mar 13, 2015 at 3:47 PM, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, Nicholas Mc Guire wrote: On Fri, 13 Mar 2015, palik imre wrote: On Friday, 13 March 2015, 13:43, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, palik imre wrote: Sorry for the silly question, but I have some issues with this checkpatch.pl warning. I mean Documentation/CodingStyle says: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. But checkpatch.pl claims I should align to open parentheses. These two things seem to be contradictory to me. Could somebody clarify this? leading tabs *followed* by spaces to align parameters to a function are fine The emacs settings in Documentation/CodingStyle seem to contradict to you, as it is set up to use c-lineup-arglist-tabs-only The problem is that CodingStyle does not explicitly address parameter alignment for functions that do not fit on a single line but checkpatch.pl does you can try it out - if you align to the opening braces with spaces with preceding TABs it will not fuss and this is also common practice. here is a quick shot at summarizing this If the parameter list to a functions would exceed the 80 char limit then break it at the separators, and align to opening braces, e.g.: ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout); or: int = wait_for_completion_interruptible_timeout(data-completion, PMI_TIMEOUT); Note that this is indented by tabs and then aligned with spaced to fit the opening braces. If you can not fit it even if you break the parameter list at the commas then indent by tabs only but *significantly* to the left of the opening braces, e.g.: int ret = wait_for_completion_interruptible_timeout( info-done, usecs_to_jiffies(TIMEOUT_US)); would be suprised if there is no writeup somewhere alredy but I did not find this covered in Documentations anywhere. I think it would be a coding idea to have this in CodingStyle doc :). At this level of detail it would be almost unmaintainable and also you would end up with far too many rules to actually keep them in mind. That is the job of tools like checkpatch.pl they can have all the myriads of corner cases encoded without creating a burden to the developers/maintainers. thx! hofrat I often see people writing posts to this list stating that they are want to get started and want to contribute something. I suppose this thread provides a suggestion for them. Take the latest version of checkpatch .pl and reverse engineer from it an update to the coding style document that documents in plain, human readable English what that script implements. Seems it bit back asswards to me for the requirements to derive from a script that implements them, but that seems to be where we are at. The very fact that this thread even exists, that the original question needed to be asked demonstrates that there's something missing in the style document. If you look at things like MISRA-C - 200+ Rules to follow for safe code it turns out that basically nobody is able to write MISRA compliant code under consideration of all 200+ rules unless they have tools that tell them what is wrong with enough information that it can be fixed. And at the same time having those rules codified makes it hard (if not impossible) to update/maintain these rules - lots of which are actually out of date or overstated but now can't be fixed - It might help to have this up on a web-page/wiki somewhere - but if you put this into Documentation/CodingStyle at this granularity the rate of people reading
RE: CHECK: Alignment should match open parenthesis
-Original Message- From: Nicholas Mc Guire [mailto:der.h...@hofr.at] Sent: Friday, March 13, 2015 9:59 AM To: Jeff Haran Cc: Daniel Baluta; kernelnewbies@kernelnewbies.org; palik imre Subject: Re: CHECK: Alignment should match open parenthesis On Fri, 13 Mar 2015, Jeff Haran wrote: -Original Message- From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Nicholas Mc Guire Sent: Friday, March 13, 2015 8:33 AM To: Daniel Baluta Cc: kernelnewbies@kernelnewbies.org; palik imre Subject: Re: CHECK: Alignment should match open parenthesis On Fri, 13 Mar 2015, Daniel Baluta wrote: On Fri, Mar 13, 2015 at 3:47 PM, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, Nicholas Mc Guire wrote: On Fri, 13 Mar 2015, palik imre wrote: On Friday, 13 March 2015, 13:43, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, palik imre wrote: Sorry for the silly question, but I have some issues with this checkpatch.pl warning. I mean Documentation/CodingStyle says: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. But checkpatch.pl claims I should align to open parentheses. These two things seem to be contradictory to me. Could somebody clarify this? leading tabs *followed* by spaces to align parameters to a function are fine The emacs settings in Documentation/CodingStyle seem to contradict to you, as it is set up to use c-lineup-arglist-tabs-only The problem is that CodingStyle does not explicitly address parameter alignment for functions that do not fit on a single line but checkpatch.pl does you can try it out - if you align to the opening braces with spaces with preceding TABs it will not fuss and this is also common practice. here is a quick shot at summarizing this If the parameter list to a functions would exceed the 80 char limit then break it at the separators, and align to opening braces, e.g.: ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout); or: int = wait_for_completion_interruptible_timeout(data-completion, PMI_TIMEOUT); Note that this is indented by tabs and then aligned with spaced to fit the opening braces. If you can not fit it even if you break the parameter list at the commas then indent by tabs only but *significantly* to the left of the opening braces, e.g.: int ret = wait_for_completion_interruptible_timeout( info-done, usecs_to_jiffies(TIMEOUT_US)); would be suprised if there is no writeup somewhere alredy but I did not find this covered in Documentations anywhere. I think it would be a coding idea to have this in CodingStyle doc :). At this level of detail it would be almost unmaintainable and also you would end up with far too many rules to actually keep them in mind. That is the job of tools like checkpatch.pl they can have all the myriads of corner cases encoded without creating a burden to the developers/maintainers. thx! hofrat I often see people writing posts to this list stating that they are want to get started and want to contribute something. I suppose this thread provides a suggestion for them. Take the latest version of checkpatch .pl and reverse engineer from it an update to the coding style document that documents in plain, human readable English what that script implements. Seems it bit back asswards to me for the requirements to derive from a script that implements them, but that seems to be where we are at. The very fact that this thread even exists, that the original question needed to be asked demonstrates that there's something missing in the style document. If you look at things like MISRA-C - 200+ Rules to follow for safe code it turns out that basically nobody is able to write MISRA compliant code under consideration of all 200+ rules unless they have tools that tell them what is wrong with enough information that it can be fixed. And at the same time having those rules codified makes it hard (if not impossible) to update/maintain these rules - lots of which are actually out of date or overstated but now can't be fixed - It might help to have this up on a web-page/wiki somewhere - but if you put this into Documentation/CodingStyle at this granularity the rate of people reading and keeping it cache-hot while coding would sharply decline. I'm not familiar with MISRA-C (it appears to be a non-open standard from the wiki I just read about it,
Missing sys_enter_open events
Hi all I am doing ftrace to track files being opened and mapped by process but sys_enter_open is getting missed and getname is being traced which is called by sys_open only. What is happening.? mem-2474 [005] 681774.985957: getnameprobe: (sys_execve+0x21/0x5a - getname) arg1=bin/mem mem-2474 [001] 683183.894867: sync_read: (vfs_read+0xab/0x107 - do_sync_read) arg1=80 mem-2474 [001] 683183.894900: sync_read: (vfs_read+0xab/0x107 - do_sync_read) arg1=1c0 mem-2474 [001] 683183.894902: sync_read: (vfs_read+0xab/0x107 - do_sync_read) arg1=1c mem-2474 [001] 683183.894913: sync_read: (vfs_read+0xab/0x107 - do_sync_read) arg1=80 mem-2474 [001] 683183.895113: sync_read: (vfs_read+0xab/0x107 - do_sync_read) arg1=188 mem-2474 [001] 683183.895275: getnameprobe: (do_sys_open+0x3b/0x105 - getname) arg1=/etc/ld.so.cache mem-2474 [001] 683183.895316: getnameprobe: (do_sys_open+0x3b/0x105 - getname) arg1=/lib/libc.so.6 mem-2474 [001] 683183.895321: sys_read(fd: 4, buf: 7fff8461a0f8, count: 340) mem-2474 [001] 683183.895328: sync_read: (vfs_read+0xab/0x107 - do_sync_read) arg1=340 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Help with learning scheduler O(1)
On Fri, Mar 13, 2015 at 2:36 AM, Meyer Lansky marku...@inbox.ru wrote: Hello all continue to study the scheduler is O(1) there was one difficulty with the string 2 on 3, in that these blocking occurs after lines? a reference to the code that study - http://lxr.free-electrons.com/source/kernel/sched.c?v=2.6.36 what I learn on line 4682 to 4695. 1 rcu_read_lock(); 2 pcred = __task_cred(p); 3 match = (cred-euid == pcred-euid || cred-euid == pcread-uid); 4 rcu_read_unlock(); I ask because in the comments there is not described. Thank. Hi I am not clear about your question. perhaps specifically you asked about why rcu_read_lock() is called? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re:question scheduler
hello I do not understand that these two lines do pcred = __task_cred(p); match = (cred-euid == pcred-euid || cred-euid == pcread-uid); or what they mean ? excuse me for my bad english . ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CHECK: Alignment should match open parenthesis
On Fri, Mar 13, 2015 at 3:47 PM, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, Nicholas Mc Guire wrote: On Fri, 13 Mar 2015, palik imre wrote: On Friday, 13 March 2015, 13:43, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, palik imre wrote: Sorry for the silly question, but I have some issues with this checkpatch.pl warning. I mean Documentation/CodingStyle says: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. But checkpatch.pl claims I should align to open parentheses. These two things seem to be contradictory to me. Could somebody clarify this? leading tabs *followed* by spaces to align parameters to a function are fine The emacs settings in Documentation/CodingStyle seem to contradict to you, as it is set up to use c-lineup-arglist-tabs-only The problem is that CodingStyle does not explicitly address parameter alignment for functions that do not fit on a single line but checkpatch.pl does you can try it out - if you align to the opening braces with spaces with preceding TABs it will not fuss and this is also common practice. here is a quick shot at summarizing this If the parameter list to a functions would exceed the 80 char limit then break it at the separators, and align to opening braces, e.g.: ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout); or: int = wait_for_completion_interruptible_timeout(data-completion, PMI_TIMEOUT); Note that this is indented by tabs and then aligned with spaced to fit the opening braces. If you can not fit it even if you break the parameter list at the commas then indent by tabs only but *significantly* to the left of the opening braces, e.g.: int ret = wait_for_completion_interruptible_timeout( info-done, usecs_to_jiffies(TIMEOUT_US)); would be suprised if there is no writeup somewhere alredy but I did not find this covered in Documentations anywhere. I think it would be a coding idea to have this in CodingStyle doc :). Daniel. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CHECK: Alignment should match open parenthesis
On Fri, Mar 13, 2015 at 04:35:30PM +0200, Daniel Baluta wrote: On Fri, Mar 13, 2015 at 3:47 PM, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, Nicholas Mc Guire wrote: On Fri, 13 Mar 2015, palik imre wrote: On Friday, 13 March 2015, 13:43, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, palik imre wrote: Sorry for the silly question, but I have some issues with this checkpatch.pl warning. I mean Documentation/CodingStyle says: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. But checkpatch.pl claims I should align to open parentheses. These two things seem to be contradictory to me. Could somebody clarify this? leading tabs *followed* by spaces to align parameters to a function are fine The emacs settings in Documentation/CodingStyle seem to contradict to you, as it is set up to use c-lineup-arglist-tabs-only The problem is that CodingStyle does not explicitly address parameter alignment for functions that do not fit on a single line but checkpatch.pl does you can try it out - if you align to the opening braces with spaces with preceding TABs it will not fuss and this is also common practice. here is a quick shot at summarizing this If the parameter list to a functions would exceed the 80 char limit then break it at the separators, and align to opening braces, e.g.: ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout); or: int = wait_for_completion_interruptible_timeout(data-completion, PMI_TIMEOUT); Note that this is indented by tabs and then aligned with spaced to fit the opening braces. If you can not fit it even if you break the parameter list at the commas then indent by tabs only but *significantly* to the left of the opening braces, e.g.: int ret = wait_for_completion_interruptible_timeout( info-done, usecs_to_jiffies(TIMEOUT_US)); would be suprised if there is no writeup somewhere alredy but I did not find this covered in Documentations anywhere. I think it would be a coding idea to have this in CodingStyle doc :). Really? Do you want to codify every tiny thing here? Just use common sense people, it's not that big of a deal... greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CHECK: Alignment should match open parenthesis
On Fri, 13 Mar 2015, palik imre wrote:
Sorry for the silly question, but I have some issues with this checkpatch.pl
warning.
I mean Documentation/CodingStyle says:
Outside of comments, documentation and except in Kconfig, spaces are never
used for indentation, and the above example is deliberately broken.
But checkpatch.pl claims I should align to open parentheses. These two
things seem to be contradictory to me. Could somebody clarify this?
leading tabs *followed* by spaces to align parameters to a function are fine
but for basic block indentation you never use spaces. so
func(param1,
param2);
would be allowed but not
if (something) {
if(something else) {
HTH
thx!
hofrat
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
CHECK: Alignment should match open parenthesis
Sorry for the silly question, but I have some issues with this checkpatch.pl warning. I mean Documentation/CodingStyle says: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. But checkpatch.pl claims I should align to open parentheses. These two things seem to be contradictory to me. Could somebody clarify this? Thanks, Imre ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CHECK: Alignment should match open parenthesis
On Friday, 13 March 2015, 13:43, Nicholas Mc Guire der.h...@hofr.at wrote:
On Fri, 13 Mar 2015, palik imre wrote:
Sorry for the silly question, but I have some issues with this
checkpatch.pl warning.
I mean Documentation/CodingStyle says:
Outside of comments, documentation and except in Kconfig, spaces are never
used for indentation, and the above example is deliberately broken.
But checkpatch.pl claims I should align to open parentheses. These two
things seem to be contradictory to me. Could somebody clarify this?
leading tabs *followed* by spaces to align parameters to a function are fine
The emacs settings in Documentation/CodingStyle seem to contradict to you,
as it is set up to use c-lineup-arglist-tabs-only
but for basic block indentation you never use spaces. so
func(param1,
param2);
would be allowed but not
if (something) {
if(something else) {
HTH
thx!
hofrat
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CHECK: Alignment should match open parenthesis
On Fri, 13 Mar 2015, Daniel Baluta wrote: On Fri, Mar 13, 2015 at 3:47 PM, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, Nicholas Mc Guire wrote: On Fri, 13 Mar 2015, palik imre wrote: On Friday, 13 March 2015, 13:43, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, palik imre wrote: Sorry for the silly question, but I have some issues with this checkpatch.pl warning. I mean Documentation/CodingStyle says: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. But checkpatch.pl claims I should align to open parentheses. These two things seem to be contradictory to me. Could somebody clarify this? leading tabs *followed* by spaces to align parameters to a function are fine The emacs settings in Documentation/CodingStyle seem to contradict to you, as it is set up to use c-lineup-arglist-tabs-only The problem is that CodingStyle does not explicitly address parameter alignment for functions that do not fit on a single line but checkpatch.pl does you can try it out - if you align to the opening braces with spaces with preceding TABs it will not fuss and this is also common practice. here is a quick shot at summarizing this If the parameter list to a functions would exceed the 80 char limit then break it at the separators, and align to opening braces, e.g.: ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout); or: int = wait_for_completion_interruptible_timeout(data-completion, PMI_TIMEOUT); Note that this is indented by tabs and then aligned with spaced to fit the opening braces. If you can not fit it even if you break the parameter list at the commas then indent by tabs only but *significantly* to the left of the opening braces, e.g.: int ret = wait_for_completion_interruptible_timeout( info-done, usecs_to_jiffies(TIMEOUT_US)); would be suprised if there is no writeup somewhere alredy but I did not find this covered in Documentations anywhere. I think it would be a coding idea to have this in CodingStyle doc :). At this level of detail it would be almost unmaintainable and also you would end up with far too many rules to actually keep them in mind. That is the job of tools like checkpatch.pl they can have all the myriads of corner cases encoded without creating a burden to the developers/maintainers. thx! hofrat ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CHECK: Alignment should match open parenthesis
On Fri, Mar 13, 2015 at 5:33 PM, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, Daniel Baluta wrote: On Fri, Mar 13, 2015 at 3:47 PM, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, Nicholas Mc Guire wrote: On Fri, 13 Mar 2015, palik imre wrote: On Friday, 13 March 2015, 13:43, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, palik imre wrote: Sorry for the silly question, but I have some issues with this checkpatch.pl warning. I mean Documentation/CodingStyle says: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. But checkpatch.pl claims I should align to open parentheses. These two things seem to be contradictory to me. Could somebody clarify this? leading tabs *followed* by spaces to align parameters to a function are fine The emacs settings in Documentation/CodingStyle seem to contradict to you, as it is set up to use c-lineup-arglist-tabs-only The problem is that CodingStyle does not explicitly address parameter alignment for functions that do not fit on a single line but checkpatch.pl does you can try it out - if you align to the opening braces with spaces with preceding TABs it will not fuss and this is also common practice. here is a quick shot at summarizing this If the parameter list to a functions would exceed the 80 char limit then break it at the separators, and align to opening braces, e.g.: ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout); or: int = wait_for_completion_interruptible_timeout(data-completion, PMI_TIMEOUT); Note that this is indented by tabs and then aligned with spaced to fit the opening braces. If you can not fit it even if you break the parameter list at the commas then indent by tabs only but *significantly* to the left of the opening braces, e.g.: int ret = wait_for_completion_interruptible_timeout( info-done, usecs_to_jiffies(TIMEOUT_US)); would be suprised if there is no writeup somewhere alredy but I did not find this covered in Documentations anywhere. I think it would be a coding idea to have this in CodingStyle doc :). At this level of detail it would be almost unmaintainable and also you would end up with far too many rules to actually keep them in mind. That is the job of tools like checkpatch.pl they can have all the myriads of corner cases encoded without creating a burden to the developers/maintainers. I see. Thanks! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: CHECK: Alignment should match open parenthesis
-Original Message- From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Nicholas Mc Guire Sent: Friday, March 13, 2015 8:33 AM To: Daniel Baluta Cc: kernelnewbies@kernelnewbies.org; palik imre Subject: Re: CHECK: Alignment should match open parenthesis On Fri, 13 Mar 2015, Daniel Baluta wrote: On Fri, Mar 13, 2015 at 3:47 PM, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, Nicholas Mc Guire wrote: On Fri, 13 Mar 2015, palik imre wrote: On Friday, 13 March 2015, 13:43, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, palik imre wrote: Sorry for the silly question, but I have some issues with this checkpatch.pl warning. I mean Documentation/CodingStyle says: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. But checkpatch.pl claims I should align to open parentheses. These two things seem to be contradictory to me. Could somebody clarify this? leading tabs *followed* by spaces to align parameters to a function are fine The emacs settings in Documentation/CodingStyle seem to contradict to you, as it is set up to use c-lineup-arglist-tabs-only The problem is that CodingStyle does not explicitly address parameter alignment for functions that do not fit on a single line but checkpatch.pl does you can try it out - if you align to the opening braces with spaces with preceding TABs it will not fuss and this is also common practice. here is a quick shot at summarizing this If the parameter list to a functions would exceed the 80 char limit then break it at the separators, and align to opening braces, e.g.: ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout); or: int = wait_for_completion_interruptible_timeout(data-completion, PMI_TIMEOUT); Note that this is indented by tabs and then aligned with spaced to fit the opening braces. If you can not fit it even if you break the parameter list at the commas then indent by tabs only but *significantly* to the left of the opening braces, e.g.: int ret = wait_for_completion_interruptible_timeout( info-done, usecs_to_jiffies(TIMEOUT_US)); would be suprised if there is no writeup somewhere alredy but I did not find this covered in Documentations anywhere. I think it would be a coding idea to have this in CodingStyle doc :). At this level of detail it would be almost unmaintainable and also you would end up with far too many rules to actually keep them in mind. That is the job of tools like checkpatch.pl they can have all the myriads of corner cases encoded without creating a burden to the developers/maintainers. thx! hofrat I often see people writing posts to this list stating that they are want to get started and want to contribute something. I suppose this thread provides a suggestion for them. Take the latest version of checkpatch .pl and reverse engineer from it an update to the coding style document that documents in plain, human readable English what that script implements. Seems it bit back asswards to me for the requirements to derive from a script that implements them, but that seems to be where we are at. The very fact that this thread even exists, that the original question needed to be asked demonstrates that there's something missing in the style document. Just my 2 cents worth, Jeff Haran ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CHECK: Alignment should match open parenthesis
On Fri, 13 Mar 2015, Jeff Haran wrote: -Original Message- From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Nicholas Mc Guire Sent: Friday, March 13, 2015 8:33 AM To: Daniel Baluta Cc: kernelnewbies@kernelnewbies.org; palik imre Subject: Re: CHECK: Alignment should match open parenthesis On Fri, 13 Mar 2015, Daniel Baluta wrote: On Fri, Mar 13, 2015 at 3:47 PM, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, Nicholas Mc Guire wrote: On Fri, 13 Mar 2015, palik imre wrote: On Friday, 13 March 2015, 13:43, Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 13 Mar 2015, palik imre wrote: Sorry for the silly question, but I have some issues with this checkpatch.pl warning. I mean Documentation/CodingStyle says: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. But checkpatch.pl claims I should align to open parentheses. These two things seem to be contradictory to me. Could somebody clarify this? leading tabs *followed* by spaces to align parameters to a function are fine The emacs settings in Documentation/CodingStyle seem to contradict to you, as it is set up to use c-lineup-arglist-tabs-only The problem is that CodingStyle does not explicitly address parameter alignment for functions that do not fit on a single line but checkpatch.pl does you can try it out - if you align to the opening braces with spaces with preceding TABs it will not fuss and this is also common practice. here is a quick shot at summarizing this If the parameter list to a functions would exceed the 80 char limit then break it at the separators, and align to opening braces, e.g.: ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout); or: int = wait_for_completion_interruptible_timeout(data-completion, PMI_TIMEOUT); Note that this is indented by tabs and then aligned with spaced to fit the opening braces. If you can not fit it even if you break the parameter list at the commas then indent by tabs only but *significantly* to the left of the opening braces, e.g.: int ret = wait_for_completion_interruptible_timeout( info-done, usecs_to_jiffies(TIMEOUT_US)); would be suprised if there is no writeup somewhere alredy but I did not find this covered in Documentations anywhere. I think it would be a coding idea to have this in CodingStyle doc :). At this level of detail it would be almost unmaintainable and also you would end up with far too many rules to actually keep them in mind. That is the job of tools like checkpatch.pl they can have all the myriads of corner cases encoded without creating a burden to the developers/maintainers. thx! hofrat I often see people writing posts to this list stating that they are want to get started and want to contribute something. I suppose this thread provides a suggestion for them. Take the latest version of checkpatch .pl and reverse engineer from it an update to the coding style document that documents in plain, human readable English what that script implements. Seems it bit back asswards to me for the requirements to derive from a script that implements them, but that seems to be where we are at. The very fact that this thread even exists, that the original question needed to be asked demonstrates that there's something missing in the style document. If you look at things like MISRA-C - 200+ Rules to follow for safe code it turns out that basically nobody is able to write MISRA compliant code under consideration of all 200+ rules unless they have tools that tell them what is wrong with enough information that it can be fixed. And at the same time having those rules codified makes it hard (if not impossible) to update/maintain these rules - lots of which are actually out of date or overstated but now can't be fixed - It might help to have this up on a web-page/wiki somewhere - but if you put this into Documentation/CodingStyle at this granularity the rate of people reading and keeping it cache-hot while coding would sharply decline. thx! hofrat ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
