From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 02:00:28 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E7EB16A418; Tue, 12 Feb 2008 02:00:28 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id ED78613C455; Tue, 12 Feb 2008 02:00:27 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 3033F1CD; Mon, 11 Feb 2008 19:40:57 -0600 (CST) Date: Mon, 11 Feb 2008 19:40:57 -0600 From: "Christian S.J. Peron" To: arch@freebsd.org Message-ID: <20080212014057.GA6027@sub.vaned.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: re@freebsd.org, current@freebsd.org Subject: sysv IPC and shminfo ABI X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2008 02:00:28 -0000 All, A while ago, I committed a patch which changed what was a kernel private structure 'shminfo'. In order to access this structure, you must define _KERNEL which suggests to me we should not be making guarantees about it's size. See /usr/src/sys/shm.h The change was incomplete, as the intent of the change was to allow us to use more then 2 Gigs of shared memory. jkim has some patches which completes the change, but they have not been committed yet. However, we do export IPC_INFO which can be used in shmctl(), and we pass this structure to userspace, which to be implies that this change can break the ABI, even though the user has to define _KERNEL to acces the structure. System V IPC is tricky like this. So I guess I have a few questions: (1) Is struct shminfo considered a sys V standard structure that has a predefined size that should be maintained across all architectures? (2) Is this an ABI breakage that we care about? Usually whether or not we want to break the ABI is clear, however in this case I am confused, because we offer IPC_INFO, implement it in the kernel, however we don't expose the details of the structure that shmctl(IPC_INFO) will export. I've done some pretty extensive searching and I can't seem to find any FreeBSD code which implements this. I know that this is late in the release engineering cycle for RELENG_7_0 to be bringing this up, but I want to make sure this isnt going to be a problem moving forward. As I see it, we have a few options: (1) Back the change out now before any damage is done (assuming we care) (2) Apply this safety patch to RELENG_7 and RELENG_7_0 http://people.freebsd.org/~csjp/sysv_shm.1202744975.6_abi_fix.diff (3) Leave things as they are, as we are going to be getting support for large shared memory allocations in the future. (This is why I asked if the structure supposed to be a standard size). I apologize for this, I understand this is probably the last thing we need before the release, but I just want to make sure that we are doing the right thing.