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 testing a new
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
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.)
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_SECMODEL
On Wed, Jun 16, 2010 at 10:27:16AM +0200, Joerg Sonnenberger wrote:
On Wed, Jun 16, 2010 at 06:30:23AM +, YAMAMOTO Takashi wrote:
i think ucontext is more flexible because this way the kernel doesn't
need to know which register etc is used for tls.
The amount of code in kernel to support
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
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
Andrew Doran a...@netbsd.org wrote:
- The dup code for fork1() code makes me uncomfortable. Maybe it's
worthwhile changing our native code so that LIDs are always allocated
from the PID table or something along those lines? Tend to think these
should be globally unique with the system
