From owner-freebsd-current@FreeBSD.ORG Mon Jul 17 17:25:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3E6216A4E0; Mon, 17 Jul 2006 17:25:05 +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 286B243D78; Mon, 17 Jul 2006 17:25:04 +0000 (GMT) (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 8F64F46C50; Mon, 17 Jul 2006 13:25:03 -0400 (EDT) Date: Mon, 17 Jul 2006 18:25:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200607171256.00539.jhb@freebsd.org> Message-ID: <20060717182314.O26409@fledge.watson.org> References: <20060712125112.W61255@is.park.rambler.ru> <200607171256.00539.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Igor Sysoev , freebsd-current@freebsd.org Subject: Re: 2Gb SYSVSHM limitation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 17:25:06 -0000 On Mon, 17 Jul 2006, John Baldwin wrote: > On Wednesday 12 July 2006 04:58, Igor Sysoev wrote: > >> the current kernel limit of SysV memory segment is 2G. Today it is too >> small for amd64 machines. >> >> Year ago Christian S.J. Peron had propsed the patch >> http://people.freebsd.org/~csjp/bigsharedmem.1117028863.diff to increase >> the limit: >> http://freebsd.rambler.ru/bsdmail/freebsd-current_2005/msg05627.html >> >> Are objections against this patch ? > > Well, it breaks the ABI of shminfo. :( Changing the ABI of structures shared > with userspace like this requires duplicate syscalls, etc. to not break > existing binaries (such as existing 6.x amd64 binaries). We're well-overdue for an ABI roll on the System V IPC data structures, but when we do this, we need to be careful to: (a) Provide the compat bits properly. (b) Make sure we fix all the things that need fixing. The current ipc perm data structure contains the following fields: struct ipc_perm { unsigned short cuid; /* creator user id */ unsigned short cgid; /* creator group id */ unsigned short uid; /* user id */ unsigned short gid; /* group id */ unsigned short mode; /* r/w permission */ unsigned short seq; /* sequence # (to generate unique ipcid) */ key_t key; /* user specified msg/sem/shm key */ }; While here, we should fix the above uids and gids do be of appropriate data types. McAfee did the first step here by breaking out kernel and user data structures a few years ago as part of the MAC Framework work, but we'll need new bits to do the next part for compat system calls. Robert N M Watson Computer Laboratory University of Cambridge