Current-Users archive

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

Re: MODULAR option and advertised semaphore support

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
+       struct sysctlnode node = *rnode;
+       module_autoload("ksem", MODULE_CLASS_MISC);
+       node.sysctl_data = &posix_semaphores;
+       return (sysctl_lookup(SYSCTLFN_CALL(&node)));

- Jukka.

Home | Main Index | Thread Index | Old Index