Re: 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 ...

[ Available lists | Index of cvs-src | Month of Mar 2009 | Week of 10 Mar 2009 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Daniel Eischen <deischen@freebsd.org>
Date
10 Mar 2009 03:37:29
Subject
Re: 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 ...
Message-ID
Pine.GSO.4.64.0903092311160.13711@sea.ntplx.net


[ Hide this part ]
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.

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

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.

--
DE

Elapsed time: 0.209 seconds