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