Date: Mon, 9 Mar 2009 08:15:16 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: David Xu <davidxu@freebsd.org> Cc: threads@freebsd.org, Pawel Worach <pawel.worach@gmail.com> Subject: Re: libthr does not obey WITHOUT_SYSCALL_COMPAT Message-ID: <Pine.GSO.4.64.0903090808490.9700@sea.ntplx.net> In-Reply-To: <Pine.GSO.4.64.0903090755350.9700@sea.ntplx.net> References: <d227e09e0903041123i638a12b8m5d8573cc871d1533@mail.gmail.com> <49B480F7.8040800@freebsd.org> <Pine.GSO.4.64.0903082343280.8064@sea.ntplx.net> <49B4A571.7000302@freebsd.org> <Pine.GSO.4.64.0903090114380.8422@sea.ntplx.net> <49B4B0EF.5080507@freebsd.org> <Pine.GSO.4.64.0903090755350.9700@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Mar 2009, Daniel Eischen wrote:
> On Mon, 9 Mar 2009, David Xu wrote:
>
>> Daniel Eischen wrote:
>>> On Mon, 9 Mar 2009, David Xu wrote:
>>>
>>>> I don't know when it appeared. Would this patch eliminate the shit ?
>>>
>>> I think so. But I think for future ABI changes to cancellation
>>> points, wouldn't we need syscall wrappers in libc? Reason, libc
>>> and libthr are now symbol-versioned, so there will no longer be
>>> library bumps for ABI changes. But if a syscall is a cancellation
>>> point and libthr has to play games with it, like fcntl, I think
>>> there should be a wrapper around it in libc. If the ABI changes,
>>> then both libc and libthr would need to provide a compat version
>>> for it. I think. ;-)
>>>
>>
>> Yes, it is better to use versioning instead, I don't know why fcntl_compat
>> is there without using this feature.
>
> Hmm, looking a little closer at this... It looks like there
> is a wrapper for fcntl in libc (libc/sys/fcntl.c). But I think
> it should always be built. Currently, it is hidden behind
> WITHOUT_SYSCALL_COMPAT in libc/sys/Makefile. But it never calls
> an older fcntl syscall. It just transforms the old style struct
^^^ new
> into new style, then calls the new fcntl syscall.
^^^ old
> So I think the mistake is building fcntl.c conditionally, when
> it should always be built regardless of WITHOUT_SYSCALL_COMPAT
> being defined or not defined.
I guess if the default is with syscall compat, then it is okay
to build optionally without it.
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0903090808490.9700>