a question regarding <sys/shm.h>

[Pascal Hofstee]

On Thu, 2007-02-15 at 13:41 +0000, Robert Watson wrote:
> Unfortunately, things are a bit more tricky.  The problem is not so much the 
> API, where converting size_t/int is a relative non-event, rather, the ABI.  By 
> changing the size of a field in a data structure, you may change the layout of 
> the structure, and hence the offset of other fields.  This offset information 
> is compiled into binaries that access the structure -- hence being part of the 
> ABI.  On i386, the change from int to size_t doesn't modify the ABI, as both 
> int and size_t are 32-bit.  However, on 64-bit platforms, int is 32-bit and 
> size_t is 64-bit:
> 
> sledge:/tmp> uname -a
> FreeBSD sledge.freebsd.org 7.0-CURRENT FreeBSD 7.0-CURRENT #898: Wed Feb 14 
> 14:20:16 UTC 2007     root at sledge.freebsd.org:/h/src/sys/amd64/compile/SLEDGE 
> amd64
> sledge:/tmp> ./size_t
> sizeof int: 4
> sizeof size_t: 8
> 
> In practice, this means that all of the later fields in the data structure 
> will be offset by 4 bytes.  This will affect any application that accesses 
> later fields in the structure but isn't recompiled.  This is why DES and I 
> have been discussing this change as requiring kernel compatibility code, which 
> would provide new system calls working with the new layout, and retain old 
> system calls working with the old layout.  So we'd need to provide a new 
> shmctl() with the new structure, and an oshmctl() with the old layout.  While 
> doing that, it makes sense to do all the other ABI-related things that we'd 
> like to get out of the way, such as fixing the types in shm_perm.

I understand ... i'll leave this up to you guys .. you have obviously a
lot more hands on experience in these kinds of matters :)

-- 
  Pascal Hofstee