Re: Modularizing net80211 (was: link_set info needed)
On Sat, 28 Apr 2012, Paul Goyette wrote:
For built-in modules, we don't (seem to) have a list of the kernel's program
sections, and the module's mod-mod_kobj is NULL. So we can't use the
section table to get the start address or size of the section. We do have the
start/end symbols that __link_set_foreach() uses to enumerate the members.
For non-built-in modules (whether loaded by boot loader, or later from the
file system), we have the section info (it's in the kobj-ko_progtab member),
but we don't seem to get the start/end symbols. (Perhaps this could be
resolved with some crt*.o type magic, but it appears that the user-land crt
stuff is GPL'd so not suitable for kernel use?)
So it seems that we just can't get a single mechanism to work for all modules
regardless of source (built-in, boot, or filesys).
I'd still like to find a way forward with this issue.
Since we can differentiate (both at compile time and at run-time)
between the two modes (built-in vs loaded), I'd like to propose adding
the data to support both modes into the mod_info_t structure:
typedef union {
struct {/* For built-in modules */
void *list_start;
void *list_end;
} func_list;
const char *section;/* For loaded modules */
} func_list_t;
typedef struct module {
u_int mod_fbtentries; /* DTrace FBT entrie count */
int mod_flags;
func_list_t mod_ctors, mod_dtors;
#define MODFLG_MUST_FORCE 0x01
#define MODFLG_AUTO_LOADED 0x02
} module_t;
Then the MODULE (or MODULE_NEW) macro can intialize the appropriate
members of the unions, and the run-time code can find the start and end
of the link_set section.
Comments?
-
| 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 |
-
Re: Modularizing net80211 (was: link_set info needed)
On Mon, Apr 30, 2012 at 06:52:52AM -0700, Paul Goyette wrote:
I'd still like to find a way forward with this issue.
Since we can differentiate (both at compile time and at run-time)
between the two modes (built-in vs loaded), I'd like to propose adding
the data to support both modes into the mod_info_t structure:
typedef union {
struct {/* For built-in modules */
void *list_start;
void *list_end;
} func_list;
const char *section;/* For loaded modules */
} func_list_t;
typedef struct module {
u_int mod_fbtentries; /* DTrace FBT entrie count */
int mod_flags;
func_list_t mod_ctors, mod_dtors;
#define MODFLG_MUST_FORCE 0x01
#define MODFLG_AUTO_LOADED0x02
} module_t;
Then the MODULE (or MODULE_NEW) macro can intialize the appropriate
members of the unions, and the run-time code can find the start and end
of the link_set section.
Comments?
I might try to find some round tuits to look at the kernel module
links.
But I've a more pressing request for a few days at least.
David
--
David Laight: da...@l8s.co.uk
Re: Modularizing net80211 (was: link_set info needed)
On Sep 18, 11:45am, David Laight wrote:
} Subject: Re: Modularizing net80211 (was: link_set info needed)
}
} 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.
}
} Thinks a bit further...
} Have each module define a snall structure that contains (say):
} - it's name
} - the address of a list of modules it depends on
} - the address of its constructors
} - the address of its destructios
You mean something like this, which is what modules do today:
/* 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 modinfo_t;
mi_required is a comma seperated list of dependencies. This structure
could be expanded.
}-- End of excerpt from David Laight
Re: Modularizing net80211 (was: link_set info needed)
On Fri, 27 Apr 2012, Joerg Sonnenberger wrote:
On Fri, Apr 27, 2012 at 06:34:40AM -0700, Paul Goyette wrote:
On Fri, 27 Apr 2012, Joerg Sonnenberger wrote:
On Fri, Apr 27, 2012 at 05:51:30AM -0700, Paul Goyette wrote:
3. Replacing the use of link_set with direct calls to all of the
crypto/auth initializers.
I believe this to a noticable regression due to bugs in the module
framework. It should support either link sets or _init sections.
If the latter is supposed to be the way forward, current linkset usage
should be adjusted and an appropiate place in the kernel for calling all
static initializers be found.
Thanks for the feedback. I am not familiar with the _init
sections stuff - can you provide a reference or example?
That's effectively how __attribute__((constructor)) or the corrsponding
C++ functionality is implemented. The necessary clue in userland is
crt*.o, would wouldn't be that hard to adopt for kernel usage.
I took a look at this, at it seems to be fairly straight-forward to
allow constructors/destructors in modules. The attached patch will
invoke a module's constructors immediately before the xxx_modcmd(INIT)
call, and the destructors will be called immediately after the
xxx_modcmd(FINI).
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.
-
| 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 |
-Index: kern_module.c
===
RCS file: /cvsroot/src/sys/kern/kern_module.c,v
retrieving revision 1.86
diff -u -p -r1.86 kern_module.c
--- kern_module.c 4 Dec 2011 19:24:59 - 1.86
+++ kern_module.c 28 Apr 2012 14:20:56 -
@@ -98,6 +98,8 @@ static void module_enqueue(module_t *);
static boolmodule_merge_dicts(prop_dictionary_t, const prop_dictionary_t);
+static voidmodule_do_tors(const char *, module_t *);
+
static voidsysctl_module_setup(void);
/*
@@ -1055,6 +1057,11 @@ module_do_load(const char *name, bool is
goto fail;
}
}
+ /*
+* If module has constructors, call them now
+*/
+ module_do_tors(.ctors, mod);
+
prev_active = module_active;
module_active = mod;
error = (*mi-mi_modcmd)(MODULE_CMD_INIT, filedict ? filedict : props);
@@ -1145,6 +1152,11 @@ module_do_unload(const char *name, bool
error);
return error;
}
+ /*
+* If module has destructors, call them
+*/
+ module_do_tors(.dtors, mod);
+
module_count--;
TAILQ_REMOVE(module_list, mod, mod_chain);
for (i = 0; i mod-mod_nrequired; i++) {
@@ -1431,3 +1443,26 @@ out:
return !error;
}
+
+/*
+ * Call the list of contructors/destructors, if any
+ */
+
+typedef void (*tor_func_t)(void);
+
+static void
+module_do_tors(const char *section, module_t *mod)
+{
+ tor_func_t f, *s_addr;
+ size_t s_size;
+
+ if (kobj_find_section(mod-mod_kobj, section, (void **)s_addr, s_size)
+ != 0)
+ return;
+ KASSERT(s_size % sizeof(f) == 0);
+ while (s_size 0) {
+ f = *(s_addr++);
+ s_size -= sizeof(f);
+ (*f)();
+ }
+}
Re: Modularizing net80211 (was: link_set info needed)
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. Thinks a bit further... Have each module define a snall structure that contains (say): - it's name - the address of a list of modules it depends on - the address of its constructors - the address of its destructios Then you can control the order of initialisers as well. David -- David Laight: da...@l8s.co.uk
Re: Modularizing net80211 (was: link_set info needed)
On Sat, 28 Apr 2012, 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. Thinks a bit further... Have each module define a snall structure that contains (say): - it's name - the address of a list of modules it depends on - the address of its constructors - the address of its destructios Then you can control the order of initialisers as well. The problem (at least, in the net80211 module case) is to not require any single source file to know the entire set of constructors. There are various crypto-algorithms which may or may not be included in the final module, and the contructors register their presence. The link_set mechanism solves this in the non-MODULE case by creating a user-defined program section to which any source file can contribute. But the symbols that point to the start and end address of the link-set program section aren't accessible in the MODULE case. The .ctors/.dtors approach works fine for the MODULE case, since the program section is specific to the module itself. But this doesn't work in the built-into-kernel case, since all constructors for all modules (and other, non-module code) would get intermingled without any control over ordering or segregation into a single kernel-wide section. - | 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 | -
Re: Modularizing net80211 (was: link_set info needed)
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. Joerg
Re: Modularizing net80211 (was: link_set info needed)
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. - | 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 | -
Re: Modularizing net80211 (was: link_set info needed)
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: da...@l8s.co.uk
Re: Modularizing net80211 (was: link_set info needed)
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: da...@l8s.co.uk
!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 |
-
Re: Modularizing net80211 (was: link_set info needed)
On Sat, 28 Apr 2012, Paul Goyette wrote:
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 \
}; \
Unfortunately, this approach doesn't work for built-in modules.
For built-in modules, we don't (seem to) have a list of the kernel's
program sections, and the module's mod-mod_kobj is NULL. So we can't
use the section table to get the start address or size of the section.
We do have the start/end symbols that __link_set_foreach() uses to
enumerate the members.
For non-built-in modules (whether loaded by boot loader, or later from
the file system), we have the section info (it's in the kobj-ko_progtab
member), but we don't seem to get the start/end symbols. (Perhaps this
could be resolved with some crt*.o type magic, but it appears that the
user-land crt stuff is GPL'd so not suitable for kernel use?)
So it seems that we just can't get a single mechanism to work for all
modules regardless of source (built-in, boot, or filesys).
-
| 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 |
-
Modularizing net80211 (was: link_set info needed)
Folks,
I would like to commit the attached patches to modularize the net80211
code. The changes include:
1. Protecting the inclusion of opt_inet.h with #ifdef _KERNEL
2. Removing CTLFLAG_PERMANENT from all of the sysctl(8) variables
3. Replacing the use of link_set with direct calls to all of the
crypto/auth initializers.
At a future time, I propose to split the crypto/auth stuff out into
their own modules, but that will require a bit more planning and a lot
more testing. :)
I have tested the attached changes on my home system, using a modular
if_rum(4) driver (which I plan to commit separately).
Comments/feedback welcomed...
-
| 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 |
-Index: ieee80211.c
===
RCS file: /cvsroot/src/sys/net80211/ieee80211.c,v
retrieving revision 1.53
diff -u -p -r1.53 ieee80211.c
--- ieee80211.c 5 Apr 2010 07:22:24 - 1.53
+++ ieee80211.c 27 Apr 2012 12:34:49 -
@@ -43,7 +43,9 @@ __KERNEL_RCSID(0, $NetBSD: ieee80211.c,
* IEEE 802.11 generic handler
*/
+#if defined(_KERNEL_OPT)
#include opt_inet.h
+#endif
#include sys/param.h
#include sys/systm.h
Index: ieee80211_crypto.c
===
RCS file: /cvsroot/src/sys/net80211/ieee80211_crypto.c,v
retrieving revision 1.15
diff -u -p -r1.15 ieee80211_crypto.c
--- ieee80211_crypto.c 23 May 2011 15:37:36 - 1.15
+++ ieee80211_crypto.c 27 Apr 2012 12:34:49 -
@@ -39,7 +39,9 @@ __FBSDID($FreeBSD: src/sys/net80211/iee
__KERNEL_RCSID(0, $NetBSD: ieee80211_crypto.c,v 1.15 2011/05/23 15:37:36
drochner Exp $);
#endif
+#if defined(_KERNEL_OPT)
#include opt_inet.h
+#endif
/*
* IEEE 802.11 generic crypto support.
Index: ieee80211_input.c
===
RCS file: /cvsroot/src/sys/net80211/ieee80211_input.c,v
retrieving revision 1.72
diff -u -p -r1.72 ieee80211_input.c
--- ieee80211_input.c 31 Dec 2011 20:41:58 - 1.72
+++ ieee80211_input.c 27 Apr 2012 12:34:49 -
@@ -39,7 +39,9 @@ __FBSDID($FreeBSD: src/sys/net80211/iee
__KERNEL_RCSID(0, $NetBSD: ieee80211_input.c,v 1.72 2011/12/31 20:41:58
christos Exp $);
#endif
+#if defined(_KERNEL_OPT)
#include opt_inet.h
+#endif
#ifdef __NetBSD__
#endif /* __NetBSD__ */
Index: ieee80211_ioctl.c
===
RCS file: /cvsroot/src/sys/net80211/ieee80211_ioctl.c,v
retrieving revision 1.57
diff -u -p -r1.57 ieee80211_ioctl.c
--- ieee80211_ioctl.c 31 Dec 2011 20:41:58 - 1.57
+++ ieee80211_ioctl.c 27 Apr 2012 12:34:50 -
@@ -43,8 +43,10 @@ __KERNEL_RCSID(0, $NetBSD: ieee80211_io
* IEEE 802.11 ioctl support (FreeBSD-specific)
*/
+#if defined(_KERNEL_OPT)
#include opt_inet.h
#include opt_compat_netbsd.h
+#endif
#include sys/endian.h
#include sys/param.h
Index: ieee80211_netbsd.c
===
RCS file: /cvsroot/src/sys/net80211/ieee80211_netbsd.c,v
retrieving revision 1.20
diff -u -p -r1.20 ieee80211_netbsd.c
--- ieee80211_netbsd.c 19 Nov 2011 22:51:25 - 1.20
+++ ieee80211_netbsd.c 27 Apr 2012 12:34:50 -
@@ -40,6 +40,7 @@ __KERNEL_RCSID(0, $NetBSD: ieee80211_ne
#include sys/kernel.h
#include sys/systm.h
#include sys/mbuf.h
+#include sys/module.h
#include sys/proc.h
#include sys/sysctl.h
#include sys/once.h
@@ -72,6 +73,8 @@ static int ieee80211_sysctl_node(SYSCTLF
intieee80211_debug = 0;
#endif
+#ifdef NOTYET /* Currently we can't use link sets in modules */
+
typedef void (*ieee80211_setup_func)(void);
__link_set_decl(ieee80211_funcs, ieee80211_setup_func);
@@ -81,7 +84,7 @@ ieee80211_init0(void)
{
ieee80211_setup_func * const *ieee80211_setup, f;
-__link_set_foreach(ieee80211_setup, ieee80211_funcs) {
+ __link_set_foreach(ieee80211_setup, ieee80211_funcs) {
f = (void*)*ieee80211_setup;
(*f)();
}
@@ -96,6 +99,29 @@ ieee80211_init(void)
RUN_ONCE(ieee80211_init_once, ieee80211_init0);
}
+#else
+/*
+ * One-time initialization
+ *
+ * XXX Make sure you update the list of CYPTO initializers if new
+ * XXX mechanisms are added!
+ */
+
+void ccmp_register(void);
+void tkip_register(void);
+void wep_register(void);
+void ieee80211_external_auth_setup(void);
+
+void
+ieee80211_init(void)
+{
+
+ ccmp_register();
+ tkip_register();
+ wep_register();
+ ieee80211_external_auth_setup();
+}
+#endif /* NOT_YET */
static
Re: Modularizing net80211 (was: link_set info needed)
On Fri, Apr 27, 2012 at 05:51:30AM -0700, Paul Goyette wrote: 3. Replacing the use of link_set with direct calls to all of the crypto/auth initializers. I believe this to a noticable regression due to bugs in the module framework. It should support either link sets or _init sections. If the latter is supposed to be the way forward, current linkset usage should be adjusted and an appropiate place in the kernel for calling all static initializers be found. Joerg
Re: Modularizing net80211 (was: link_set info needed)
On Fri, 27 Apr 2012, Joerg Sonnenberger wrote: On Fri, Apr 27, 2012 at 05:51:30AM -0700, Paul Goyette wrote: 3. Replacing the use of link_set with direct calls to all of the crypto/auth initializers. I believe this to a noticable regression due to bugs in the module framework. It should support either link sets or _init sections. If the latter is supposed to be the way forward, current linkset usage should be adjusted and an appropiate place in the kernel for calling all static initializers be found. Thanks for the feedback. I am not familiar with the _init sections stuff - can you provide a reference or example? Please also note that separating the crypto/auth stuff into their own modules later on will remove these direct calls to the initializers. - | 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 | -
Re: Modularizing net80211 (was: link_set info needed)
On Fri, Apr 27, 2012 at 06:34:40AM -0700, Paul Goyette wrote: On Fri, 27 Apr 2012, Joerg Sonnenberger wrote: On Fri, Apr 27, 2012 at 05:51:30AM -0700, Paul Goyette wrote: 3. Replacing the use of link_set with direct calls to all of the crypto/auth initializers. I believe this to a noticable regression due to bugs in the module framework. It should support either link sets or _init sections. If the latter is supposed to be the way forward, current linkset usage should be adjusted and an appropiate place in the kernel for calling all static initializers be found. Thanks for the feedback. I am not familiar with the _init sections stuff - can you provide a reference or example? That's effectively how __attribute__((constructor)) or the corrsponding C++ functionality is implemented. The necessary clue in userland is crt*.o, would wouldn't be that hard to adopt for kernel usage. Joerg
link_set info needed
I've been working on modularizing the ieee80211 code, and I've
discovered that the code using a link_set to collect various one-time
initialization routines. There is a RUN_ONCE() invocation that uses
__link_set_for_each() to iterate over these init routines.
This all works just fine when including net80211 in a monolithic kernel,
but for some reason, when building as a module, the link_set sections
don't seem to get created (they're not listed by objdump -h).
__link_set_for_each tries to loop through the items in
{start,stop}_link_set_set-name - these items are contributed by
other source files. But the symbols that should identify the start and
stop of the link set are undefined.
Any suggestions on an appropriate alternate to link sets to collect the
contributions?
If anyone wants to look at the actual code, it is in
src/sys/net80211/ieee80211_netbsd.[ch]
Thanks!
-
| 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 |
-
Re: link_set info needed
link set won't work for modules. ISTR pooka@ did a work-around for
RUMP or whatever.
(Ideal alternative is decent ctors/dtors support.)
On Thu, Apr 26, 2012 at 11:44 AM, Paul Goyette p...@whooppee.com wrote:
I've been working on modularizing the ieee80211 code, and I've discovered
that the code using a link_set to collect various one-time initialization
routines. There is a RUN_ONCE() invocation that uses __link_set_for_each()
to iterate over these init routines.
This all works just fine when including net80211 in a monolithic kernel, but
for some reason, when building as a module, the link_set sections don't seem
to get created (they're not listed by objdump -h).
__link_set_for_each tries to loop through the items in
{start,stop}_link_set_set-name - these items are contributed by other
source files. But the symbols that should identify the start and stop of
the link set are undefined.
Any suggestions on an appropriate alternate to link sets to collect the
contributions?
If anyone wants to look at the actual code, it is in
src/sys/net80211/ieee80211_netbsd.[ch]
Thanks!
-
| 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 |
-
