linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Nathan Chancellor <natechancellor@gmail.com>
Cc: bvanassche@acm.org, ooo@electrozaur.com,
	"James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] libosd: Remove ignored __weak attribute
Date: Thu, 25 Oct 2018 15:02:13 -0700	[thread overview]
Message-ID: <CAKwvOdn=TvoGdFvgxX6TyXBXnhVLttriRrZEnzS6DjcjL64DPA@mail.gmail.com> (raw)
In-Reply-To: <20181025213144.GB24709@flashbox>

On Thu, Oct 25, 2018 at 2:31 PM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Tue, Oct 02, 2018 at 04:06:31PM -0700, Bart Van Assche wrote:
> > On Tue, 2018-10-02 at 15:33 -0700, Nick Desaulniers wrote:
> > > On Tue, Oct 2, 2018 at 10:57 AM Bart Van Assche <bvanassche@acm.org> wrote:
> > > > Explicitly initialized global and static variables end up in the .data
> > > > section and need space in that section.
> > >
> > > Unless the initial value is zero.
> > > https://godbolt.org/z/curRoO
> > >
> > > So you don't wind up with an increase in binary size simply by having
> > > global variables initialized to zero, right?  Instead the kernel knows
> > > to create a zero'd out mapping for bss.  You don't need a run of zeros
> > > in the binary.
> > >
> > > So I disagree when you said earlier "zero initializers should be left
> > > out to minimize the size of object files." I assert they don't affect
> > > the size of the binary.
> > >
> > > If you had many global variables all initialized to zero, why would
> > > you encode that many zeros in a binary, when you can just set a size
> > > on the bss section and have the kernel create the appropriate sized
> > > and zero'd mapping?
> > >
> > > > That is not the case if the
> > > > initializer is left out and these variables end up in the .bss section.
> > >
> > > From my above link, gcc will put globals without initializers into "common."
> >
> > No matter what particular compiler versions do with explicit initialization
> > to zero, the preferred kernel coding style is to leave out such explicit
> > initialization.
> >
> > Bart.
>
> Hi Bart,
>
> I'm sorry if I didn't follow the conclusion of this conversation properly
> but this is the below diff you were initially looking for, correct?
>
> If so, Boaz and Nick, do you have any objections if this is v2? I'd like
> to get this patch accepted so the warning can be fixed for everyone.

Hi Nathan,
Thanks for following up on this.  Bart's note about the one definition
rule is important.  If you define the variable static in two different
translation units, you've suddenly created two different copies
accessible only to their respective translation units.  So it should
be declared extern in one source file (but not defined/initialized),
and defined (non-static) in another.  See below for example.

>
> Thanks,
> Nathan
>
> ================================================================================
>
> diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
> index e19fa883376f..4250f739beb3 100644
> --- a/drivers/scsi/osd/osd_initiator.c
> +++ b/drivers/scsi/osd/osd_initiator.c
> @@ -58,6 +58,8 @@
>
>  enum { OSD_REQ_RETRIES = 1 };
>
> +static const struct osd_obj_id osd_root_object;

extern const struct osd_obj_id osd_root_object;

> +
>  MODULE_AUTHOR("Boaz Harrosh <ooo@electrozaur.com>");
>  MODULE_DESCRIPTION("open-osd initiator library libosd.ko");
>  MODULE_LICENSE("GPL");
> diff --git a/drivers/scsi/osd/osd_uld.c b/drivers/scsi/osd/osd_uld.c
> index eaf36ccf58db..770c758baaa9 100644
> --- a/drivers/scsi/osd/osd_uld.c
> +++ b/drivers/scsi/osd/osd_uld.c
> @@ -73,6 +73,7 @@
>
>  static const char osd_name[] = "osd";
>  static const char *osd_version_string = "open-osd 0.2.1";
> +static const struct osd_obj_id osd_root_object;

const struct osd_obj_id osd_root_object;

>
>  MODULE_AUTHOR("Boaz Harrosh <ooo@electrozaur.com>");
>  MODULE_DESCRIPTION("open-osd Upper-Layer-Driver osd.ko");
> diff --git a/include/scsi/osd_types.h b/include/scsi/osd_types.h
> index 48e8a165e136..eb31357ec8b3 100644
> --- a/include/scsi/osd_types.h
> +++ b/include/scsi/osd_types.h
> @@ -28,8 +28,6 @@ struct osd_obj_id {
>         osd_id id;
>  };
>
> -static const struct __weak osd_obj_id osd_root_object = {0, 0};
> -

LGTM

>  struct osd_attr {
>         u32 attr_page;
>         u32 attr_id;

That way the linker knows there's only one instance of this struct in
memory, and that the two different translation units are referring to
the same instance.  The other maintainers may have a preference which
translation you define osd_root_object in (I arbitrarily chose
drivers/scsi/osd/osd_uld.c), but if they don't have additional
feedback after some amount of time, I'd assume they're ok with the
above suggestion.  What do you think?

-- 
Thanks,
~Nick Desaulniers

  reply	other threads:[~2018-10-25 22:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-30 20:54 [PATCH] libosd: Remove ignored __weak attribute Nathan Chancellor
2018-10-01 22:47 ` Nick Desaulniers
2018-10-02  1:16 ` Bart Van Assche
2018-10-02  6:55   ` Nathan Chancellor
2018-10-02 14:56   ` Christoph Hellwig
2018-10-02 16:59     ` Boaz Harrosh
2018-10-02 17:24   ` Nick Desaulniers
2018-10-02 17:57     ` Bart Van Assche
2018-10-02 22:33       ` Nick Desaulniers
2018-10-02 23:06         ` Bart Van Assche
2018-10-25 21:31           ` Nathan Chancellor
2018-10-25 22:02             ` Nick Desaulniers [this message]
2018-10-25 22:55               ` Nathan Chancellor
2018-10-26 17:54                 ` Nick Desaulniers
2018-10-26 18:01                   ` Bart Van Assche
2018-10-26 18:05                     ` Nathan Chancellor
2018-10-26 18:31                       ` Nick Desaulniers
2018-10-26 19:22                         ` Linus Torvalds
2018-10-26 20:05                           ` Nick Desaulniers
2018-10-26 20:42                             ` Linus Torvalds
2018-10-26 21:02                               ` Nick Desaulniers
2018-10-26 21:00                     ` Nick Desaulniers
2018-10-26 21:30                       ` Bart Van Assche
2018-10-26 21:36                         ` Nick Desaulniers
2018-10-26 21:59                           ` Bart Van Assche
2018-10-26 22:07                             ` Nick Desaulniers
2018-10-26 22:24                               ` Bart Van Assche
2018-10-27 13:28                                 ` Martin K. Petersen
2018-10-28 15:44                                   ` Christoph Hellwig
2018-11-01  1:05                                   ` Boaz Harrosh
2018-10-27  3:35                               ` Theodore Y. Ts'o
2018-10-27  6:15                                 ` Bart Van Assche
2018-10-27  6:25                                   ` Nathan Chancellor
2018-11-01  1:15                   ` Boaz Harrosh
2018-11-01  1:39             ` Boaz Harrosh
2018-11-01  1:44               ` Nathan Chancellor
2019-01-26  6:47 ` [PATCH RESEND] " Nathan Chancellor

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='CAKwvOdn=TvoGdFvgxX6TyXBXnhVLttriRrZEnzS6DjcjL64DPA@mail.gmail.com' \
    --to=ndesaulniers@google.com \
    --cc=bvanassche@acm.org \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=natechancellor@gmail.com \
    --cc=ooo@electrozaur.com \
    /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).