NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: kern/37427 document _ksem_* syscalls
The following reply was made to PR kern/37427; it has been noted by GNATS.
From: matthew green <mrg%eterna.com.au@localhost>
To: paul%whooppee.com@localhost
Cc: gnats-bugs%NetBSD.org@localhost, pgoyette%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost,
netbsd-bugs%netbsd.org@localhost, mmondor%pulsar-zone.net@localhost
Subject: re: kern/37427 document _ksem_* syscalls
Date: Sun, 29 Nov 2015 09:44:44 +1100
> >> We currently have man pages for sem(4) with cross-refs to several other
> >> pages for the specific functions.
> >>
> >> Is there any reason why this is insufficient? If this is OK, I will
> >> close the PR.
> >
> > is there documentation on the backend that is sufficient? how is
> > someone supposed to look at the sem(4) code without understanding
> > the system calls that back it?
> >
> > i don't agree that "hidden" functionality should not be documented,
> > and for actual system calls i don't believe that "in the sources"
> > suffices.
>
> Ah, so in addition to wanting the syscalls themselves documented
> (which we have already), you want to see a ksem(9) man page
> describing the internal workings?
>
> Let me see if I can do something here... Step 1 - study code ...
i don't need ksem(9) exactly -- that could be largely in the
comments in the code. i wouldn't object to it.
it's the user/kernel boundary, even if largely hidden from users,
deserves to be properly documented. it might be documented as
being a backend and point to the normal entry points that should
be used instead.
thanks!
.mrg.
Home |
Main Index |
Thread Index |
Old Index