Date: Wed, 13 Jan 2016 23:48:21 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: John Baldwin <jhb@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r293783 - head/lib/libc/sys Message-ID: <20160113224821.GA5118@stack.nl> In-Reply-To: <2902719.QmmqeCdr7g@ralph.baldwin.cx> References: <201601122053.u0CKrvmB060658@repo.freebsd.org> <2902719.QmmqeCdr7g@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 13, 2016 at 08:58:12AM -0800, John Baldwin wrote: > On Tuesday, January 12, 2016 08:53:57 PM Jilles Tjoelker wrote: > > Author: jilles > > Date: Tue Jan 12 20:53:57 2016 > > New Revision: 293783 > > URL: https://svnweb.freebsd.org/changeset/base/293783 > > Log: > > Update futimens/utimensat for MFC to stable/10: > > * Fix __FreeBSD_version check. > > * Update history section in man page. > > An MFC of this commit to stable/10 will allow using the new system calls > > instead of the fallback. > > MFC after: 3 days > Why does futimens.c exist? Given that we do not support forwards > compatibility (newer libc on older kernel) only backwards > compatibility (older libc on newer kernel), libc should just always > call the system call directly. This is what we do for all other > system calls and would avoid the issue of the earlier MFC not actually > working. Allowing the unsupported 'make installkernel ; make > installworld ; reboot' cycle to work across this change doesn't seem > worth the effort of maintaining the osreldate checks here. It turns out that many people do, in fact, rely on combinations of new userland and slightly older kernel not breaking horribly. For example, portmgr does not update the kernel on package building nodes as often as the -current userland, and users may try older kernels for bisection purposes. When I committed SOCK_CLOEXEC and SOCK_NONBLOCK without compatibility code, years ago, I got many complaints. Therefore, I think compatibility code for old kernels should be added if it is not too onerous (such as here), particularly if an API is added that already exists on other platforms. An example where I think compatibility would be too onerous is reaper (procctl(PROC_REAP_ACQUIRE) and friends). In practice, compatibility code is inconsistently added. Some old examples where it was added are the removal of padding for 64-bit syscall parameters and changes to struct flock (both were removed in r281714). As a result, one or a few major versions later, the compatibility code is unlikely to be useful and should be removed. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160113224821.GA5118>