Re: MODULAR option and advertised semaphore support

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

On Sat, Nov 06, 2010 at 01:19:31PM +0100, Nicolas Joly wrote:
> 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.
>
> _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.

But how can it predict whether or not the corresponding syscall, and the
loading of the module, will succeed? If I manually delete the module (for
whatever reason), shouldn't this mean that the functionality embedded in the
module is no longer supported?

> > It is also unclear to me how a module can load itself.
> 
> A module cannot load itself, someone else must load it.


Right. I misread the location of this:
     
 /*  
+ * sysctl helper routine for kern.posix_semaphores
+ */ 
+static int
+sysctl_kern_posix_semaphores(SYSCTLFN_ARGS)
+{   
+       struct sysctlnode node = *rnode;
+
+       module_autoload("ksem", MODULE_CLASS_MISC);
+
+       node.sysctl_data = &posix_semaphores;
+       return (sysctl_lookup(SYSCTLFN_CALL(&node)));
+}

- Jukka.