Re: Modularizing net80211 (was: link_set info needed)

[Paul Goyette <paul%whooppee.com@localhost>]

How about another alternative?

Rather than using .ctor/dtor for _MODULE mode, and a link-set for the 
built-in mode, we could extend the modinfo_t structure to include two 
new members:

        char *mi_ctor_section, *mi_dtor_section

Then the module's code can continue to use the link_set paradigm, and 
the module loader can use the names provided rather than hard-coding 
".ctor" and ".dtor".  And that means that (this part of) the module 
doesn't need to be aware of whether it is built-in or not.

This would also mean that net80211 module no longer needs its own code 
to process the __link_set_foreach(), since the module loader would take 
care of this automatically?

Of course, this would definitely require a kernel version bump, since 
module_t would be changing.  And I would propose we use a MODULE_NEW 
declaration, and redefine MODULE to specify NULL values for the two new 
members.

/* Module header structure. */
typedef struct modinfo {
        u_int           mi_version;
        modclass_t      mi_class;
        int             (*mi_modcmd)(modcmd_t, void *);
        const char      *mi_name;
        const char      *mi_required;
        const char      *mi_ctor_section;
        const char      *mi_dtor_section;
} const modinfo_t;

...

/*
 * Per-module linkage.  Loadable modules have a `link_set_modules' section
 * containing only one entry, pointing to the module's modinfo_t record.
 * For the kernel, `link_set_modules' can contain multiple entries and
 * records all modules built into the kernel at link time.
 */
#define MODULE(class, name, required)                           \
        MODULE_NEW(class, name, required, NULL, NULL)

#define MODULE_NEW(class, name, required, ctor, dtor)           \
static int name##_modcmd(modcmd_t, void *);                     \
static const modinfo_t name##_modinfo = {                       \
        .mi_version = __NetBSD_Version__,                       \
        .mi_class = (class),                                    \
        .mi_modcmd = name##_modcmd,                             \
        .mi_name = #name,                                       \
        .mi_required = (required),                              \
        .mi_ctor_section = ctor,                                \
        .mi_dtor_section = dtor                                 \
};                                                              \




On Sat, 28 Apr 2012, David Laight wrote:

> On Sat, Apr 28, 2012 at 10:13:11AM -0700, Paul Goyette wrote:
> > On Sat, 28 Apr 2012, Joerg Sonnenberger wrote:
> >
> > > On Sat, Apr 28, 2012 at 05:09:16PM +0100, David Laight wrote:
> > > > > This mechanism only works for modules that are "separate" from the
> > > > > kernel (loaded via "boot" or from "filesys").  "builtin" modules still
> > > > > need to use the link_set mechanism.
> > > >
> > > > Shouldn't be that hard to put the contructor list address into a
> > > > link_set - that would make it easy to get them called for 'built in'
> > > > modules.
> > >
> > > It's not even that complicated. Just provide symbols for start and end
> > > of the .ctor / .dtor section. That can be done either using linker
> > > scripts or by prepending / appending a small object like crt* does.
> >
> > But can you provide symbols for the start/end of each module's portion
> > of the .ctor / .dtor section?  I don't think you can even guarantee that
> > all contributions for a module would be co-located.  And I don't think
> > you would want to call all contructors for all (built-in) modules at the
> > same time, so you'd need a way to identify which entries belong to each
> > module.  This is essentially what the link_set mechanism does today -
> > the net80211 module (and other stuff) each gets its own .ctor section.
>
> You could rename (or maybe name) the modules section to .ctor.module,
> then you'd need to add a list of the .ctor.module names into the
> linker script to getthem called in the right order.
>
> I think the rename would be enough to get the symbols together.
>
> Other schemes that might work involve doing an initial 'ld -r'
> for the module, then processing the output of objdump/nm to generate an
> extra object file to link into the output.
> I'm not sure whether youcan use a linker script to control an 'ld -r'.
>
>         David
>
> --
> David Laight: david%l8s.co.uk@localhost
>
> !DSPAM:4f9c3c472405365912897!

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------