Re: MODULAR option and advertised semaphore support

[Nicolas Joly <njoly%pasteur.fr@localhost>]

On Sat, Nov 06, 2010 at 07:41:27AM +0200, Jukka Ruohonen wrote:
> On Fri, Nov 05, 2010 at 11:33:45PM +0100, Nicolas Joly wrote:
> > On Fri, Nov 05, 2010 at 06:05:14PM +0100, Nicolas Joly wrote:
> > > On Fri, Nov 05, 2010 at 05:02:09PM +0100, Matthias Drochner wrote:
> > > > 
> > > > If I understand it correctly, with Nicolas' proposal an innocent
> > > > "sysctl -a" would load the semaphore module. I don't have a better
> > > > idea yet, but this approach doesn't scale -- if done for more
> > > > modules all of them would be loaded with this single "sysctl"
> > > > invocation.
> > [...]
> > > I'm not a sysctl expert, but does making them hidden (CTLFLAG_HIDDEN)
> > > should help ? The way i understand it, only explicit calls would
> > > triggers module loading ...
> > 
> > I do checked this, and CTLFLAG_HIDDEN do indeed prevent `sysctl -a'
> > from calling/reporting it. It's only triggered for explicit request
> > `sysctl kern.posix_semaphore'.
> 
> Being in turn neither a module(9) nor a sysctl(9) expert, I would assume
> that one fundamental principle of modules is that these should completely
> clean-up after an unload, leaving no traces to the system.

Sure. But availability of a sub-system should not be embedded in the
corresponding module. By example, kern.posix_semaphores should always
be available, but some semaphore specifics such as kern.posix.semmax
which are only meaningfull if supported can be embedded in the module,
and thus cleaned-up when unloaded.

> Should a query of _SC_SEMAPHORES succeed even if the corresponding
> module does not exist?

_SC_SEMAPHORES should return 200112 if semaphores are fully supported,
which means syscalls would succeed (from kernel option, loaded module,
...); and -1 (= not supported) otherwise. But it should never fail by
lack of status.

> It is also unclear to me how a module can load itself.

A module cannot load itself, someone else must load it.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.