From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 20:35:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D91FAE8C for ; Thu, 28 Aug 2014 20:35:55 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 624971D57 for ; Thu, 28 Aug 2014 20:35:54 +0000 (UTC) X-AuditID: 1209190f-f79aa6d000005b45-b4-53ff92a3fa71 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id D0.C1.23365.3A29FF35; Thu, 28 Aug 2014 16:35:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7SKZkQt015760; Thu, 28 Aug 2014 16:35:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7SKZiim032329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Aug 2014 16:35:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7SKZiOL020337; Thu, 28 Aug 2014 16:35:44 -0400 (EDT) Date: Thu, 28 Aug 2014 16:35:44 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Steven Stewart-Gallus Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nort40v9gg5+tKhbbN/9jtJj5eR67 A5PHjE/zWTxO/nvLEsAUxWWTkpqTWZZapG+XwJXRcOkVS8EztYpTk/MaGDfIdTFyckgImEgc nnSCHcIWk7hwbz1bFyMXh5DAbCaJZ9+esEA4GxklTn19xgRSJSRwiEnidVc6RKKBUeJCxxcW kASLgLbE/xcfWUFsNgE1icd7m1khxipKbD41iRnEFhGwkfjXNoMNxGYWkJe4sPkQI4gtLBAu sWnnKrA5nAJGEg++nABaxsHBK+Ao0XTPF2KvocT9x1PBykUFdCRW758CVs4rIChxcuYTFoiR WhLLp29jmcAoNAtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxhB 4cspyb+D8dtBpUOMAhyMSjy8MxL+BQuxJpYVV+YeYpTkYFIS5VXv/x8sxJeUn1KZkVicEV9U mpNafIhRgoNZSYS3oAoox5uSWFmVWpQPk5LmYFES531rbRUsJJCeWJKanZpakFoEk5Xh4FCS 4P05AahRsCg1PbUiLTOnBCHNxMEJMpwHaLjZRJDhxQWJucWZ6RD5U4yKUuK8u0GaBUASGaV5 cL2w9PKKURzoFWFeN5B2HmBqgut+BTSYCWjwr46/IINLEhFSUg2MYgyqj+O4M/iCi055LI9S XK10nXXxMqcZkoVHZ1ZtrJv54gR/fMC+bz2O/D/PmXuuLePZUM1vE6ug2qrXcOn9wVj+6eUd zx/u7QwTWlBWEnfg3NnqJfLZbey+j/8saOPavVjzxtPtDaIr2fd7Gv69y6fqH17nf6wuzHqz ivoRMda/11wYpl9VYinOSDTUYi4qTgQAgdaabQoDAAA= Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:35:56 -0000 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