Date: Sat, 19 Jan 2008 07:13:16 -0500 From: David Schultz <das@FreeBSD.ORG> To: Jung-uk Kim <jkim@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] SysV SHM on 64-bit platforms Message-ID: <20080119121316.GA21917@VARK.MIT.EDU> In-Reply-To: <200801181217.52788.jkim@FreeBSD.org> References: <200801181217.52788.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 18, 2008, Jung-uk Kim wrote: > Because fixing this PR breaks ABI, I had to make compat shims. But > the question is which branch to break? Since we are very close to > 7.0-RELEASE, the question became more complicated. A lot of people > are asking me to fix this PR because it is much needed fix for large > database installations, so I have to make a quick decision. :-( It's far too late to fix it for 7.0. RC1 is out, the packages have already been built, and this could potentially break things. In particular, you have no way of guaranteeing that an "old" shared library that uses semctl(2) linked with a "new" binary will work properly, or vise versa. For 8-CURRENT, I'd say go ahead and fix it and add the syscall compat goop. Then I guess backport it to 7-STABLE after a while if nothing important breaks and nobody has any objections to that plan. It would also be cool if struct ipcperm got fixed at the same time so we only have to do this once. I think that only entails adding compat crud to semctl and maybe one or two other syscalls. Those changes aren't urgent enough to make it worthwhile to backport to 7.X IMO, though. Two questions/comments about the patches: - Why the #if !defined(__i386__)? There are better ways to test whether you're compiling for a 32-bit architecture, if that's what you meant. - The 8.X version needs to take the p_osrel for the equivalent change in 7.X into account.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080119121316.GA21917>