Date: Tue, 11 Jan 2000 10:35:27 -0800 From: Jason Evans <jasone@canonware.com> To: "Richard Seaman, Jr." <dick@tar.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Adding alternate entry points to libc (was Re: Possible libc changes to support LinuxThreads) Message-ID: <20000111103527.A302@sturm.canonware.com> In-Reply-To: <19991209064256.B34152@tar.com>; from dick@tar.com on Thu, Dec 09, 1999 at 06:42:56AM -0600 References: <19991209003517.E73529@sturm.canonware.com> <19991209064256.B34152@tar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:
> It's my impression that glibc uses a three (four?) tiered naming
> convention. The "pure" syscall (in our case, eg. _write()). Then
> there is the version used internally in glibc (eg. _libc_write().
> And finally, the version exported from glibc (eg. write()).
>
> The merit to the three tiered system is that you might need to rewrite
> the version used internally to libc for threads, but still have this
> be different from the version exported from the library (eg. to
> implement cancallation points without propagating them throughout
> libc).
>
> In this case, you'd want, for example, an _lseek(), _libc_lseek(),
> and _seek().
>
> The problem with cancellation points, libc and linuxthreads has been
> that you need to wade through libc and replace instances of, for
> example, write() with either _write() or _libc_write() in order to
> avoid propagating cancellation points where they don't belong.
I'm working on adding alternate entry points to libc now. The naming
approach I'm taking is:
fwrite() <-- Alternate entry point that is used externally unless
another library overrides it.
_libc_fwrite() <-- `_libc_' prefix. Alternate entry point for internal
library use.
__fwrite() <-- `__' prefix. Actual name.
The reason for a prefix of `__' instead of `_' in the actual name case is
that using only one underscore would be ambiguous at least in the cases of
setjmp()/_setjmp() and longjmp()/_longjmp().
One issue I'm not sure on is whether *every* libc interface should have
alternate entry points added. Doing so would be more consistent, but it
probably isn't necessary, since POSIX very clearly defines the set of
functions that may act as cancellation points. There end up being a few
other functions that need wrapped by threads libraries as well. Of course,
doing only the necessary ones is easier for me. =)
If only adding alternate entry points for the necessary libc interfaces,
there's a good chance I can get this done for 4.0, which will mean
compliant thread cancellation for both libc_r and linuxthreads. A genuine
libpthread is just a hop, skip, and a jump from there.
Jason
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000111103527.A302>