From owner-freebsd-hackers Tue Dec 10 11:36:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA24105 for hackers-outgoing; Tue, 10 Dec 1996 11:36:21 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA24089 for ; Tue, 10 Dec 1996 11:36:07 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id NAA27665; Tue, 10 Dec 1996 13:35:26 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma027646; Tue Dec 10 13:34:57 1996 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id NAA30011; Tue, 10 Dec 1996 13:35:10 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.3/8.6.12) with ESMTP id NAA16873; Tue, 10 Dec 1996 13:35:25 -0600 (CST) Message-Id: <199612101935.NAA16873@jake.lodgenet.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Marc G. Fournier" cc: "Eric L. Hernes" , hackers@FreeBSD.ORG Subject: Re: Multiple Buffer allocation of Shared Memory In-reply-to: Your message of "Tue, 10 Dec 1996 13:20:06 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Dec 1996 13:35:24 -0600 From: "Eric L. Hernes" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Marc G. Fournier" writes: > > Okay...maybe I'm missing something as far as mmap() is concerned, >but what I want to be able to do is allocated X bytes of memory to be >shared amongst several processes. After the memory is allocated, I will >*then* want to fill the memory (ie. with data read from a socket). > > From reading the mmap() man page (any good reference/textbooks that >I might want to pick up?), mmap() allocates and fills the memory space at >the same time, based on a previously opened, already existing, file (fd). > Yup, * The Design and Implemenatation of the 4.4BSD Operating System ~page 139 * UNIX Internals The New Frontiers ~page 440 One way, is to open a (previously agreed upon) named file that will be used to share data, ftruncate() it to the size you want, then mmap() it. Other processes can open and mmap() this same file to get at the data. After the mmap(), you've got a pointer to the data, you can cast it to whatever you like, just like with shmat(). The biggest problem here is that all programs will have to agree on the named file, but if you use the SysV stuff, they all have to agree on the shmid, so it's not a showstopper. Terry has already outlined a solution that avoids this problem. In a nutshell, open()/mmap() are roughly analogous to shmget()/shmat(), and munmap()/unlink() are roughly analogous to shmget()/shmctl(). One thing that named files and mmap() can buy you is persistance of data across a reboot(), whether that is good or bad is up to you. > >----- >hub> ./client >No space left on device >cannot initialize shared memory buffer #29 >----- > > At least I'm getting 28 buffers created now, instead of just >8 :) > > Now, am I understanding what I've configured correctly? With >SHMSEG=128 and SHMMAXPGS=4096, I should be able to allocate up to 128 >pages of 4096k each? I actually set SHMSEG to 256, mind you...just in case. SHMMAXPGS is in pages, so its 4096*4096, or 16Meg. I think that 16Meg is the global shared mem pool, and the 128 segments are taken out of it. As John has pointed out, the numbers are purely administrative, you may be able to remove the checks in kern/sysv_shm.c and just grant the requests, but you'll have to check the return from the lower (vm) layer that acutally returns the mapping. > >Marc G. Fournier scrappy@hub.org >Systems Administrator @ hub.org scrappy@freebsd.org > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com