libthr does not obey WITHOUT_SYSCALL_COMPAT

Daniel Eischen deischen at freebsd.org
Mon Mar 9 05:15:19 PDT 2009


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


More information about the freebsd-threads mailing list