Attached is the latest set of diffs to address this issue. To summarize
the changes:
1. Add an allocator for the 'struct module *' and use it instead of
local allocations. The source of the module (builtin, boot, or filesys)
is passed as an argument to the allocator.
2. Add a new member mo
On Thu, 17 Jun 2010, Antti Kantee wrote:
On Wed Jun 16 2010 at 15:36:30 -0700, Paul Goyette wrote:
The attached diffs add one more routine, module_init3() which gets
called from init_main() right after module_class_init(MODULE_CLASS_ANY).
module_init3() walks the list of builtin modules that ha
On Wed Jun 16 2010 at 15:36:30 -0700, Paul Goyette wrote:
> The attached diffs add one more routine, module_init3() which gets
> called from init_main() right after module_class_init(MODULE_CLASS_ANY).
> module_init3() walks the list of builtin modules that have not already
> been init'd and mar
On Wed, 16 Jun 2010, Antti Kantee wrote:
On Wed Jun 16 2010 at 06:31:59 -0700, Paul Goyette wrote:
The attached diffs add a new mod_disabled member to the module_t
structure, and set the value to false in each place that a new entry is
created. (Since all of the allocations of module_t structu
On Wed Jun 16 2010 at 06:31:59 -0700, Paul Goyette wrote:
> The attached diffs add a new mod_disabled member to the module_t
> structure, and set the value to false in each place that a new entry is
> created. (Since all of the allocations of module_t structures are done
> with kmem_zalloc() I
On Wed, 16 Jun 2010, Antti Kantee wrote:
I have to admit I haven't been following your work too closely, but
builtin modules are initialized either when all of them are initialized
per class or when their initialization is explicitly requested. So if
whatever uses PCIVERBOSE requests the load o
On Wed, Jun 16, 2010 at 09:47:54AM +0300, Antti Kantee wrote:
> On Wed Jun 16 2010 at 12:13:38 +1000, matthew green wrote:
> > i think having a class of builtin modules that are available during
> > autoconfig isn't a bad thing. perhaps the right answer is infact to
> > convert MODULE_CLASS_SECMOD
On Wed Jun 16 2010 at 04:58:37 -0700, Paul Goyette wrote:
> Yeah, my initial pass at the xxxVERBOSE modules used module_load() with
> MODCTL_LOAD_FORCE flag. And it worked just fine for both built-in and
> boot-loaded modules. Then, at John Nemeth's request, I modified it all
> to use module_a
On Wed, 16 Jun 2010, Antti Kantee wrote:
I have to admit I haven't been following your work too closely, but
builtin modules are initialized either when all of them are initialized
per class or when their initialization is explicitly requested. So if
whatever uses PCIVERBOSE requests the load o
On Tue Jun 15 2010 at 17:10:55 -0700, Paul Goyette wrote:
> Currently, built-in kernel modules are not enabled until very late in
> the system initialization process, right after we create process #1 for
> init(8). (As an exception to this, secmodel modules are enabled much
> earlier.)
>
> Unf
On Wed, 16 Jun 2010, Antti Kantee wrote:
On Wed Jun 16 2010 at 04:13:54 -0700, Paul Goyette wrote:
With the current ways of secmodel register, I'd be damn careful to not
push it around. The effect is that if it's called 0 times, you have a
system which allows everything. So if your suggestion
On Wed Jun 16 2010 at 04:13:54 -0700, Paul Goyette wrote:
> >With the current ways of secmodel register, I'd be damn careful to not
> >push it around. The effect is that if it's called 0 times, you have a
> >system which allows everything. So if your suggestion is implemented
> >and you're testin
On Wed, 16 Jun 2010, Antti Kantee wrote:
On Wed Jun 16 2010 at 12:13:38 +1000, matthew green wrote:
i think having a class of builtin modules that are available during
autoconfig isn't a bad thing. perhaps the right answer is infact to
convert MODULE_CLASS_SECMODEL into say MODULE_CLASS_EARLY,
On Wed Jun 16 2010 at 12:13:38 +1000, matthew green wrote:
> i think having a class of builtin modules that are available during
> autoconfig isn't a bad thing. perhaps the right answer is infact to
> convert MODULE_CLASS_SECMODEL into say MODULE_CLASS_EARLY, and remove
> the special case handling
On Wed, 16 Jun 2010, matthew green wrote:
I would like to enable the built-in modules much earlier, at least early
enough to have them available during auto-configuration. The attached
patch accomplishes this. I have briefly tested the patch, and it seems
not to have any unwanted side-effect
> I would like to enable the built-in modules much earlier, at least early
> enough to have them available during auto-configuration. The attached
> patch accomplishes this. I have briefly tested the patch, and it seems
> not to have any unwanted side-effects, but I would appreciate feedback
Currently, built-in kernel modules are not enabled until very late in
the system initialization process, right after we create process #1 for
init(8). (As an exception to this, secmodel modules are enabled much
earlier.)
Unfortunately, this means that built-in modules are not available for
u
17 matches
Mail list logo
