Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Aug 2014 23:31:42 +0000 (GMT)
From:      Steven Stewart-Gallus <sstewartgallus00@mylangara.bc.ca>
To:        Benjamin Kaduk <bjk@freebsd.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Can anyone help clarify details about the FreeBSD system call interface?
Message-ID:  <fc15f845287.53ffbbde@langara.bc.ca>
In-Reply-To: <alpine.GSO.1.10.1408281618310.21571@multics.mit.edu>
References:  <fb4bf68f53c5.53ff77ee@langara.bc.ca> <alpine.GSO.1.10.1408281618310.21571@multics.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
> sys_sched_yield just backends to sched_relinquish, which is defined
> (identically) in kern/sched_{ule,4bsd}.c. They differ in that 
> sys_yieldhas a check for (PRI_BASE(td->td_pri_class) == 
> PRI_TIMESHARE), and also
> that sys_sched_yield() always acts on curthread, whereas sys_yield 
> usesthe provided thread descriptor.

Okay.

> svn blame says that the whole implementation dates from r1541.  
> Looks like
> it was never implemented.  Some googling indicates that it was a 
> plannedroutine to set the stack size, which was never implemented, 
> anywhere.

> The locking comments were added in r79224, but the implementation is
> otherwise from r1541, i.e., it was never implemented.

Alright, so sys/kern/syscalls.master can be patched somewhat like so
and I won't need to document them?

-72	AUE_O_VADVISE	STD	{ int ovadvise(int anom); } vadvise \
-				    ovadvise_args int
+72	AUE_NULL	OBSOL   ovadvise

-70	AUE_SSTK	STD	{ int sstk(int incr); }
+70	AUE_SSTK	OBSOL	sstk

> It applies the indicated MAC policy for the given syscall arguments.
> I'll defer to someone else on this.

> Looks like that to me, too.  Again, I'll defer.

Okay.

> I'll defer looking at these.

Okay.

> 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#L468Conceptually 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 
> behaviorof the afs3_syscall in FreeBSD-specific documentation, I 
> think.
> -Ben

Okay, Linux has similar reserved system calls such as tuxcall. Linux
deals with these by having an unimplemented.2 manpage which lists
obsolete or reserved system calls. So we can just add to the manpage
stuff like: afs3_syscall is a system call reserved for the use of the
OpenAFS people.

Thank you,
Steven Stewart-Gallus



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fc15f845287.53ffbbde>