linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Wolff <willy.mh.wolff.ml@gmail.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] driver core: fix statics initilisation
Date: Tue, 16 Apr 2019 12:34:33 +0100	[thread overview]
Message-ID: <CACfOrNe0t0ieWbvwN_zpos-gdpc8qXVxQjHOv4FhMw8cBi5KBQ@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0gj1p0KNUZkZ3JG2ppK1706GSfY3J12mDNx-E75Y_J3Cg@mail.gmail.com>

I guess this patch will be ignored. I will drop it then.

Thanks for the discussion.

On Tue, Apr 16, 2019 at 10:50:23am +0200, Rafael J. Wysocki wrote:
> On Mon, Apr 15, 2019 at 5:29 PM Willy Wolff <willy.mh.wolff.ml@gmail.com> wrote:
> >
> > Thank you for your review.
> >
> > I follow https://kernelnewbies.org/FirstKernelPatch to write this patch.
> > It's not stated that checkpatch.pl is for new patches only. Moreover,
> > https://kernelnewbies.org/FirstKernelPatch#Running_checkpatch.pl suggest to
> > run over the entire file.
>
> I'm not sure about the source of that recommendation.
>
> In any case, running it over the entire file doesn't mean that you
> should or even need to make all of the warnings in that file go away.
>

I understand that, but it was shown as ERROR. There are some other warnings for
long lines that I skip.

> > Also, uninitialised static global variable are initialised to 0 by default.
> > Thus, initialising driver_deferred_probe_enable to false (which is 0) is
> > redundant.
>
> Yes, it is redundant, but it also is harmless AFAICS.
>
> > As my knowledge, initialised global goes to .data section, and uninitialised
> > goes to .bss.
> >
> > What does it mean for the kernel? Is this still hold?
>
> No, I don't think so.
>
> > Are performance or memory footprint of the kernel be affected?
>
> No, they aren't.
>
> The only difference this makes is the removal of redundant
> initialization to 0, which may be regarded as a cleanup, but not as a
> fix IMO.

Ok, will stated as a cleanup in the future.

>
> If that's the only reason you have to change the file in question,
> doing something else instead of that may be a better allocation of
> your time.

Thank you for your advice. I was just having my nose on it while playing with
something else, it wasn't a hide-and-seek game.

>
> Thanks!

  reply	other threads:[~2019-04-16 11:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 15:48 [PATCH 2/2] driver core: fix statics initilisation Willy Wolff
2019-04-15  8:12 ` Rafael J. Wysocki
2019-04-15 15:29   ` Willy Wolff
2019-04-16  8:50     ` Rafael J. Wysocki
2019-04-16 11:34       ` Willy Wolff [this message]
2019-04-16 13:40     ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACfOrNe0t0ieWbvwN_zpos-gdpc8qXVxQjHOv4FhMw8cBi5KBQ@mail.gmail.com \
    --to=willy.mh.wolff.ml@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).