Date: Thu, 28 Aug 2014 16:35:44 -0400 (EDT) From: Benjamin Kaduk <bjk@freebsd.org> To: Steven Stewart-Gallus <sstewartgallus00@mylangara.bc.ca> Cc: freebsd-hackers@freebsd.org Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? Message-ID: <alpine.GSO.1.10.1408281618310.21571@multics.mit.edu> In-Reply-To: <fb4bf68f53c5.53ff77ee@langara.bc.ca> References: <fb4bf68f53c5.53ff77ee@langara.bc.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Aug 2014, Steven Stewart-Gallus wrote:
> Hi, I am interested in learning more about how FreeBSD works. I have
> gathered some information on some of FreeBSD's undocumented system
> calls and am not sure it is correct. Please correct me if I am wrong
> about the following system calls. I would be happy to submit some
> patches to help out with documentation after I get some confirmation
> and clarification.
>
> int sys_yield(void);
> int sys_sched_yield(void);
>
> Not sure how sys_yield differs from sched_yield. sys_yield is defined
> in sys/kern/kern_synch.c and sys_sched_yield is defined in
> sys/kern/p1003_1b.c.
sys_sched_yield just backends to sched_relinquish, which is defined
(identically) in kern/sched_{ule,4bsd}.c. They differ in that sys_yield
has a check for (PRI_BASE(td->td_pri_class) == PRI_TIMESHARE), and also
that sys_sched_yield() always acts on curthread, whereas sys_yield uses
the provided thread descriptor.
> int sys_sstk(int incr);
>
> sys/vm/vm_mmap.c defines this as:
>
> /*
> * MPSAFE
> */
> /* ARGSUSED */
> int
> sys_sstk(td, uap)
> struct thread *td;
> struct sstk_args *uap;
> {
> /* Not yet implemented */
> return (EOPNOTSUPP);
> }
>
> Did sys_sstk use to do something in the past and is now just legacy?
svn blame says that the whole implementation dates from r1541. Looks like
it was never implemented. Some googling indicates that it was a planned
routine to set the stack size, which was never implemented, anywhere.
> int sys_vadvise(int anom);
>
> sys/vm/vm_unix.c defines this as:
>
> /*
> * MPSAFE
> */
> /* ARGSUSED */
> int
> sys_ovadvise(td, uap)
> struct thread *td;
> struct ovadvise_args *uap;
> {
> /* START_GIANT_OPTIONAL */
> /* END_GIANT_OPTIONAL */
> return (EINVAL);
> }
>
> Did sys_vadvise use to do something in the past and is now just
> legacy?
The locking comments were added in r79224, but the implementation is
otherwise from r1541, i.e., it was never implemented.
> int sys_mac_syscall(const char * policy, int call, void * arg);
>
> Not sure what sys_mac_syscall does. Seems to do a bunch of MAC
> operations at once. See sys/security/mac for a closer look.
It applies the indicated MAC policy for the given syscall arguments.
I'll defer to someone else on this.
> int sys___mac_execve(char * fname, char ** argv, char ** envv, struct
> mac * mac_p);
>
> Looks an execve that applys a MAC policy. See sys/security/mac for a
> closer look.
Looks like that to me, too. Again, I'll defer.
> int sys__umtx_lock(struct umtx * umtx);
> int sys _umtx_unlock(struct umtx * umtx);
> int sys__umtx_op(void * obj, int op, u_long val, void * uaddr1, void *
> uaddr2);
>
> Seems to implement low level mutexes. See sys/kern/kern_umtx.c for a
> closer look and lib/libthr/thread/umtx.h for the userspace wrapper.
>
> int sys_nlm_syscall(int debug_level, int grace_period, int addr_count,
> char ** addrs);
>
> Multiplexes system calls used to implement the kernel side of the
> Network Lock Manager protocol. See sys/nlm for a closer look.
I'll defer looking at these.
> int sys_nnpfs_syscall(int operation, char * a_pathP, int a_opcode,
> void * a_paramsP, int a_followSymlinks);
>
> Multiplexes system calls used to implement the kernel side of some
> filesystem thingy. Not sure what it does. I can't find out where
> this is defined in the source code.
>
> int sys_afs3_syscall(long syscall, long parm1, long parm2, long parm3,
> long parm4, long parm5, long parm6);
>
> Multiplexes system calls used to implement the kernel side of the AFS
> protocol (version 3). I can't find out where this is defined in the
> source code.
Neither of these are implemented in the tree.
Both were added for use by different implementations of the AFS protocol;
nnpfs for the "Arla" client, and afs3_syscall for the "openafs" client.
Unfortunately, OpenAFS actually uses the syscall number from the
nnpfs_syscall (IIRC), but with the semantics of afs3_syscall, to avoid
breaking existing applications.
Arla has not been functional on FreeBSD for several major versions of
FreeBSD (probably not since 4.X) and is probably not worth looking at.
OpenAFS is available at http://openafs.org or via the net/openafs port;
for example, the implementation of afs3_syscall is the tangled mess of
preprocessor conditionals starting at
https://github.com/openafs/openafs/blob/openafs-stable-1_6_x/src/afs/afs_syscall.c#L468
Conceptually it is actually a multiplexor of multiplexors (ew!), with
several operations of type AFSCALL_CALL and many others of type
AFSCALL_PIOCTL ("path ioctl"). It's out of scope to describe the behavior
of the afs3_syscall in FreeBSD-specific documentation, I think.
-Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1408281618310.21571>