tech-kern archive

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

Re: Does "options P1003_1B_SEMAPHORE" still exist?

On Mon, 17 Sep 2012 10:42:49 -0700 (PDT)
Paul Goyette <> wrote:

Sorry for the long delay, I'm slowly recouping with tech-kern mail.

> I recently noticed that there is a built-in "ksem" module that includes 
> sys/kern/uipc_sem.c
> The man page for sem(4) states that this code should be included in the 
> kernel only if "options P1003_1B_SEMAPHORE" is defined.  Yet a search of 
> the kernel sources shows no usage for this option anywhere, and the 
> uipc_sem.c file is unconditionally included by sys/conf/files
> So, I have a few questions:
> 1. Should sem(4) really be in manual section 4?  It doesn't appear to be 
> a device driver!  (Maybe a more detailed man page should be written for 
> section 9?)

I have the impression that those syscalls should all be documented in a
section 2 manual page instead (kern/37427).  Not totally related but
misc/38979 would have similar results for the scheduler control related
syscalls.  I now realize that I probably don't have a PR for these ones,
but the mqueue and setaffinity related syscalls are also undocumented.

At the time I filed the PRs they were contested by AD because the libc
counterparts were already documented, with the syscalls considered the
private interface.  I personally believe that all syscalls should be
documented in NetBSD (and recently I have learned that I'm not the only
one to think they should be, so perhaps I should eventually write these
manual pages, afterall).

> 2. Should the man page be updated to remove the reference to the option?

A quick grep on netbsd-6 here only shows:

share/man/man4/options.4:.It Cd options P1003_1B_SEMAPHORE
share/man/man4/sem.4:.Cd "options P1003_1B_SEMAPHORE"
sys/compat/freebsd/freebsd_syscall.h:#if defined(P1003_1B_SEMAPHORE) || 
sys/compat/freebsd/freebsd_syscallargs.h:#if defined(P1003_1B_SEMAPHORE) || 
sys/compat/freebsd/freebsd_syscallargs.h:#if defined(P1003_1B_SEMAPHORE) || 
sys/compat/freebsd/freebsd_syscalls.c:#if defined(P1003_1B_SEMAPHORE) || 
sys/compat/freebsd/freebsd_sysent.c:#if defined(P1003_1B_SEMAPHORE) || 
sys/compat/freebsd/syscalls.master:#if defined(P1003_1B_SEMAPHORE) || 
sys/compat/netbsd32/netbsd32_syscall.h:#if defined(P1003_1B_SEMAPHORE) || 
(!defined(_KERNEL_OPT) && defined(_LIBC))
sys/compat/netbsd32/netbsd32_syscallargs.h:#if defined(P1003_1B_SEMAPHORE) || 
(!defined(_KERNEL_OPT) && defined(_LIBC))
sys/compat/netbsd32/netbsd32_syscallargs.h:#if defined(P1003_1B_SEMAPHORE) || 
(!defined(_KERNEL_OPT) && defined(_LIBC))
sys/compat/netbsd32/netbsd32_syscalls.c:#if defined(P1003_1B_SEMAPHORE) || 
(!defined(_KERNEL_OPT) && defined(_LIBC))
sys/compat/netbsd32/netbsd32_sysent.c:#if defined(P1003_1B_SEMAPHORE) || 
(!defined(_KERNEL_OPT) && defined(_LIBC))
sys/compat/netbsd32/syscalls.master:#if defined(P1003_1B_SEMAPHORE) || 
(!defined(_KERNEL_OPT) && defined(_LIBC))
sys/kern/init_sysctl.c:#if defined(MODULAR) || defined(P1003_1B_SEMAPHORE)
sys/modules/compat_netbsd32/Makefile:CPPFLAGS+= -DP1003_1B_SEMAPHORE -DCOREDUMP 

> 3. If the code is truly unconditional, should it really be a module?  If 
> so, could it be made to auto-load when needed?  Could it also be auto 
> unloaded?

It seems that other POSIX librt components such as message queues,
scheduler control, cpu affinity, etc, are not optional.  I don't know
why those semaphores should be, thus they could probably remain as part
of the base kernel with the option removed, unless we'd want all of RT
components to be optional and in a module, perhaps?  But librt of
course wouldn't be usable then, unless it's loaded...

Anyone remember a particular reason why these semaphores might be
unwanted in custom kernels, but the rest of librt wanted anyway?

Home | Main Index | Thread Index | Old Index