cvs commit: src/lib/libc/gen lockf.c src/lib/libc/sys Symbol.map fcntl.2 src/sys/compat/freebsd32 syscalls.master src/sys/compat/linux linux_file.c src/sys/compat/svr4 svr4_fcntl.c src/sys/conf NOTES files options ...

[Doug Rabson]

On 10 Mar 2009, at 03:21, Daniel Eischen wrote:

> On Wed, 26 Mar 2008, Doug Rabson wrote:
>
>> dfr         2008-03-26 15:23:13 UTC
>>
>> FreeBSD src repository
>>
>> Modified files:
>>   lib/libc/sys         Symbol.map fcntl.2
>     [ ... ]
>>   sys/sys              fcntl.h lockf.h
>     [ ... ]
>> Log:
>> Add the new kernel-mode NFS Lock Manager. To use it instead of the
>> user-mode lock manager, build a kernel with the NFSLOCKD option and
>> add '-k' to 'rpc_lockd_flags' in rc.conf.
>
> Sorry to notice this 1 year too late, but doesn't this
> break ABI?  You have changed the size (increased) of
> struct flock and haven't really provided a compat version
> of fcntl() that will work with binaries built before
> the change.

I added new fcntl commands for the new structures. The old commands  
were renamed to F_OGETLK, F_OSETLK and F_OSETLKW and continue to use  
the old structures. A new kernel translates old fcntl commands to the  
equivalent new commands. A new libc will detect when its running on an  
old kernel and will translate the new fcntl commands to the equivalent  
old ones.

>
> Is there any way that the new field can be accidentally
> used by the kernel from a binary built against the older
> struct flock?

No.

>
> Now that we have symbol versioning, the way this normally
> should be handled is by adding a compat fcntl() for
> FBSD_1.0 in libc, and placing the new fcntl() in FBSD_1.1.
> And since libthr wraps fcntl() for cancellation points,
> I believe it would also need the same compat functions.

I thought about this but in the end it was simpler to add new fcntl  
commands. The libthr compat issue is dealt with by calling  
__fcntl_compat() for commands other than F_DUPFD, F_SETFD, F_SETFL,  
F_GETFD or F_GETFL.