From: Nathan Chancellor <natechancellor@gmail.com>
To: Nick Desaulniers <ndesaulniers@google.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:55:48 -0700 [thread overview]
Message-ID: <20181025225548.GA10326@flashbox> (raw)
In-Reply-To: <CAKwvOdn=TvoGdFvgxX6TyXBXnhVLttriRrZEnzS6DjcjL64DPA@mail.gmail.com>
On Thu, Oct 25, 2018 at 03:02:13PM -0700, Nick Desaulniers wrote:
> 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.
>
Hi Nick,
I just want to make sure I understand what is going on here.
Doesn't the first part already happen because osd_root_object is
declared static in osd_types.h? I tried this little simple example of
adding a 'static const' variable to a header file and using it in two
separate files/functions. When compiled together, they point to two
different locations in memory.
==============================================
$ clang -std=gnu89 main.c test1.c test2.c
$ ./a.out
test in test1(): 0x55b4df3a001c
test in test2(): 0x55b4df3a003c
==============================================
main.c:
#include "test.h"
int main(void) {
test1();
test2();
}
==============================================
test1.c:
#include <stdio.h>
#include "test.h"
void test1() {
printf("test in test1(): %p\n", &test);
}
==============================================
test2.c:
#include <stdio.h>
#include "test.h"
void test2() {
printf("test in test2(): %p\n", &test);
}
==============================================
test.h:
struct test_struct {
int a;
int b;
};
static const struct test_struct test = {0, 0};
void test1();
void test2();
==============================================
If that is the case, could your suggested change result in a functional
change given that the code would now refer to the same osd_root_object?
This isn't necessarily a problem, especially since it sounds like not
referring to the same object could be a bug, but I want to make sure
that's what is intended by these changes, which I'll be happy to spin up
in a v2.
If I am thinking about this incorrectly or my example is wrong in any
way, please let me know. I'm trying to soak up all of this knowledge
so I can be a better contributor.
Thanks for the reply and explanation!
Nathan
> >
> > 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
next prev parent reply other threads:[~2018-10-25 22:55 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
2018-10-25 22:55 ` Nathan Chancellor [this message]
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=20181025225548.GA10326@flashbox \
--to=natechancellor@gmail.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=ndesaulniers@google.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).