Re: [RFC] SysV SHM on 64-bit platforms

On Saturday 19 January 2008 07:13 am, David Schultz wrote:
> 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.

I know the compat shim is not bullet-proof and I perfectly understand 
your concerns.  That's why I had to give four options and three sets 
of patches. :-(

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

Well, since the policy is 'no seat belt for -CURRENT', I think that is 
aceptable, too.

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

So, you are in between option 1 and 4, i.e., bigger fix goes to HEAD 
and partial MFC to RELENG_7, right?

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

I reused oshmid_ds, which was only for __i386__ && (COMPAT_FREEBSD4 || 
COMPAT_43).  Basically I didn't want to add struct 
oh_my_god_we_did_it_again_shmid_ds. ;-)  Actually, the arch check is 
done like this:

if (sizeof(size_t) != sizeof(int) && td->td_proc->p_osrel <= WHATEVER)

I am hoping the compiler is smart enough to optimize away 
'sizeof(size_t) != sizeof(int)'.

> - The 8.X version needs to take the p_osrel for the equivalent
>   change in 7.X into account.

I thought it did, didn't it?

Jung-uk Kim