Date: Wed, 4 Apr 2001 16:32:56 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Daniel Eischen <eischen@vigrid.com> Cc: Thomas Moestl <tmm@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc_r/uthread uthread_acl_aclcheck_fd.c uthread_acl_delete_fd.c uthread_acl_get_fd.c uthread_acl_set_fd.c uthread_cap_get_fd.c uthread_cap_set_fd.c pthread_private.h Message-ID: <Pine.NEB.3.96L.1010404154618.24669A-100000@fledge.watson.org> In-Reply-To: <Pine.SUN.3.91.1010404151816.12121C-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Apr 2001, Daniel Eischen wrote: > BTW, why do all the acl system calls begin with 2 underscores? Is that > specified by the POSIX1.e standard? I believe this was actually at Bruce's recommendation. The reason is that the system calls themselves do not provide the POSIX.1e API. Instead, they are wrapped by the actual POSIX.1e API (this was one of the functions served by libposix1e). This occurs because POSIX.1e requires some of its calls to allocate memory in userspace for data returned from the kernel, and because some of the userspace structures are different from those communicated with the kernel. As examples -- acl_get_file() is intended to allocate the memory required to return the ACL information to the caller. Similarly, acl_t in userland is going to diverge from being "struct acl *" shortly because the POSIX.1e interface requires that acl_t provide access to an iterator over the ACL entries, which is not part of the kernel or persistent format. As a result, it was necessary to place the functions out of the application namespace, especially since the system call functions are in libc. The accepted way of pushing things out of the application namespace is to escape them using "__"--there was existing precedent for the __ technique in system call naming in the form of __sysctl(), __semctl(), and __getcwd(). This starts to look a little obtuse due to the libc name escaping associated with threading, but is the most consistent solution we could think of. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010404154618.24669A-100000>