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 [EMAIL PROTECTED]:/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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
