Re: [PATCH] libosd: Remove ignored __weak attribute

[Nathan Chancellor]

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@xxxxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxxxxxxx>");
> >  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@xxxxxxxxxxxxxxx>");
> >  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