From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 15 13:41:01 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB3D816A400 for ; Thu, 15 Feb 2007 13:41:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB7213C4A8 for ; Thu, 15 Feb 2007 13:41:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E80384779C; Thu, 15 Feb 2007 08:41:00 -0500 (EST) Date: Thu, 15 Feb 2007 13:41:00 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pascal Hofstee In-Reply-To: Message-ID: <20070215133647.V79543@fledge.watson.org> References: <45C04593.2090704@gmail.com> <20070131085206.GW892@turion.vk2pj.dyndns.org> <45C06167.60401@gmail.com> <86odofjyua.fsf@dwp.des.no> <20070131105024.L91177@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , hackers@freebsd.org Subject: Re: a question regarding X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 13:41:01 -0000 On Thu, 15 Feb 2007, Pascal Hofstee wrote: > On 1/31/07, Robert Watson wrote: >> If we do decide to go ahead with the ABI change, there are a number of >> other things that should be done simultaneously, such as changing the uid >> and gid fields to uid_t and gid_t. I would very much like to see the ABI >> change happen, and the first step (breaking out kernel from user >> structures) has been done already as part of the MAC work. The next step >> is to add routines that translate internal/external formats, which isn't >> hard, but requires a moderate pile of code to do (as well as great care >> :-). > > Well .. i finally found some spare time to have a closer look at the > "shm_segsz" issue ... and noticed there were actually a very limited number > of direct uses of the shm_segsz struct member (26 lines in the entire > /usr/src tree) > > I have attached a patchset that should change shm_segsz to size_t. There > were however 2 to 3 locations all regarding compat code (ibcs2, svr4 and > COMPAT_43) where i opted to stay on the clear side and not touch anything, > the rest was fairly straightforward as should be obvious from the diff. I > checked to make sure no function prototypes changed anywhere. > > Please have a look at the attached patch (available at > http://callisto.offis.uni-oldenburg.de/shm_segsz-int2size_t.diff in case the > attachment gets stripped off by the mailinglist software) and provide any > feedback where appropriate. 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@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. Robert N M Watson Computer Laboratory University of Cambridge