Re: linux kernel coding style and checkpatch.pl script
On Thu, Mar 26, 2020 at 04:01:18PM +0300, Konstantin Andreev wrote:
> Valdis Klētnieks, 26 Mar 2020 07:13 MSK:
> > Don't split literal strings, it means that grepping the source tree for
> > "already registered" fails. Making grep for a string work is more important
> > than shutting up checkpatch.
>
> On Thu, Mar 26, 2020 at 02:36:23PM +0300, Konstantin Andreev wrote:
> > Sic! Grepping is important. Given that, why are kernel functions coded in a
> >
> > | static int __init loglevel(char *str)
> > | {
> >
> > way, but not old decent unix way:
> >
> > | static int __init
> > | loglevel(char *str)
> > | {
>
> Greg KH, 26 Mar 2020 15:06 MSK:
> > Documentation/process/coding-style.rst
>
> This document does not answer my question. It does not even require
>
> | static int __init loglevel(char *str)
> | {
>
> style. Here is a relevant part of document: "separate functions with one
> blank line... EXPORT macro should follow closing function brace ... In
> function prototypes, include parameter names ... E.g.:"
>
> | int system_is_up(void)
> | {
> | return system_state == SYSTEM_RUNNING;
> | }
> | EXPORT_SYMBOL(system_is_up);
>
> That's all. Have I overlooked something? Could you, please, share your own
> point of view?
If it's not a specific rule in there, then that means you could do
someething crazy like:
static int __init
loglevel(char *str)
{
if you were so loony to do so.
But, it turns out that when you write your code like that, it's harder
to actually find where the function is defined vs. where it is called
when greping a codebase.
That's why those of us who have been at this for a long time prefer:
static int __init loglevel(char *str)
{
instead.
much easier to pick out of a list of "where is this defined" output of
'git grep'.
And yes, I know all about ctags and the like, but sometimes you don't
have access to that, or don't want to fire it up and have it pre-process
things just to look at a specific git tree at the moment.
Also, big shoutout to 'vgrep' https://github.com/vrothberg/vgrep which
makes using 'git grep' a zillion times easier and is what I rely on all
the time.
tldr;
either way is fine, but putting the return value on the function
name line usually makes it easier for others to find your code.
Hope this helps,
greg k-h
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: linux kernel coding style and checkpatch.pl script
Valdis Klētnieks, 26 Mar 2020 07:13 MSK:
Don't split literal strings, it means that grepping the source tree for "already
registered" fails. Making grep for a string work is more important than shutting up
checkpatch.
On Thu, Mar 26, 2020 at 02:36:23PM +0300, Konstantin Andreev wrote:
Sic! Grepping is important. Given that, why are kernel functions coded in a
| static int __init loglevel(char *str)
| {
way, but not old decent unix way:
| static int __init
| loglevel(char *str)
| {
Greg KH, 26 Mar 2020 15:06 MSK:
Documentation/process/coding-style.rst
This document does not answer my question. It does not even require
| static int __init loglevel(char *str)
| {
style. Here is a relevant part of document: "separate functions with one blank
line... EXPORT macro should follow closing function brace ... In function prototypes,
include parameter names ... E.g.:"
| int system_is_up(void)
| {
| return system_state == SYSTEM_RUNNING;
| }
| EXPORT_SYMBOL(system_is_up);
That's all. Have I overlooked something? Could you, please, share your own
point of view?
--
Regards, Konstantin
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: linux kernel coding style and checkpatch.pl script
On Thu, Mar 26, 2020 at 02:36:23PM +0300, Konstantin Andreev wrote:
> Valdis Klētnieks, 26 Mar 2020 07:13 MSK:
> >
> > To borrow from Pirates of the Carribean, "They're not exactly rules,
> > they're more like... suggestions..."
> >
> > Don't split literal strings, it means that grepping the source tree for
> > "already registered" fails. Making grep for a string work is more important
> > than shutting up checkpatch.
>
> Sic! Grepping is important. Given that, why are kernel functions coded in a
>
> | static int __init loglevel(char *str)
> | {
>
> way, but not old decent
>
> | static int __init
> | loglevel(char *str)
> | {
>
> unix way?
Documentation/process/coding-style.rst
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: linux kernel coding style and checkpatch.pl script
Valdis Klētnieks, 26 Mar 2020 07:13 MSK:
To borrow from Pirates of the Carribean, "They're not exactly rules, they're more
like... suggestions..."
Don't split literal strings, it means that grepping the source tree for "already
registered" fails. Making grep for a string work is more important than shutting up
checkpatch.
Sic! Grepping is important. Given that, why are kernel functions coded in a
| static int __init loglevel(char *str)
| {
way, but not old decent
| static int __init
| loglevel(char *str)
| {
unix way?
--
Regards, Konstantin
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: linux kernel coding style and checkpatch.pl script
On Wed, Mar 25, 2020 at 9:38 AM Tomek The Messenger < tomekthemessen...@gmail.com> wrote: > Hi > There is checkpatch.pl script where You can check if You wrote code in > your kernel module according to linux kernel style. > However can I ignore warning message? > WARNING: quoted string split across lines > #974: FILE: fpgax67-core.c:974: > + dev_err(>dev, "registration not done, driver is > already " > + "registered\n"); > > If I don't split line I will have another warning that 80 characters is > exceeded. > > you can put the whole string on next line and/or use "\" for splitting long string. For sure I can ignore warnings about: > WARNING: struct should normally be const > #998: FILE: fpgax67-core.c :998: > +int fpgax67_unregister(struct platform_device *pdev) > > For sure all errors must be fixed like: > const char* tmp -> change to -> const char *tmp; > if( => if ( #insert space > > Generally I don't know how much warnings should I correct. If it is > mandatory or only good practise and I can omit some if it doesn't make > sense. > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Thank you Warm Regards Anuz ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
