a question regarding <sys/shm.h>

Robert Watson rwatson at FreeBSD.org
Fri Feb 16 12:56:07 UTC 2007


On Thu, 15 Feb 2007, Pascal Hofstee wrote:

> 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 :)

Well -- don't let this discourage you from working on it, I'm just pointing 
out that there are some more details to work on before it will be done :-).
I'm happy to advise further as the work moves along, but unfortunately don't 
have time to do it myself at this point.  It's something I would very much 
like to see happen, though!

Robert N M Watson
Computer Laboratory
University of Cambridge


More information about the freebsd-hackers mailing list