tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Enabling built-in modules earlier in init

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
the special case handling for MODULE_CLASS_SECMODEL to deal with
calling secmodel_register()/secmodel_deregister() by pushing these
calls into the mi_modcmd() calls inside the secmodules themselves.

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 secmodel which buggily omits register alongside
another correctly registering secmodel, things will appear to work fine,
But if in some scenario the buggy one is loaded alone, well ... welcome
to the wishing well.

I had some concern about this as well, wondering if I would be able to be sure I'd found all the secmodel modules that might exist.

Perhaps it would be best to retain MODULE_CLASS_SECMODEL and also add the suggested MODULE_CLASS_EARLY?

Also, the modclass id is exported to userland and used as an index to
a table in modstat.  I think I filed a PR about this being suboptimal.

Yeah, I was planning to update modstat(8) as well.

Anyway, no objections, but rather things to consider and pointers where
development needs to recurse to to make the original task possible.


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

Home | Main Index | Thread Index | Old Index