From owner-freebsd-hackers  Fri Jun 28 15:21:58 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA03700
          for hackers-outgoing; Fri, 28 Jun 1996 15:21:58 -0700 (PDT)
Received: from jau.csc.fi (jau.csc.fi [193.166.1.196])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA03689
          for <hackers@freebsd.com>; Fri, 28 Jun 1996 15:21:52 -0700 (PDT)
Received: (from jau@localhost) by jau.csc.fi (8.7.5/8.6.12+CSC-2.1) id BAA23320 for hackers@freebsd.com; Sat, 29 Jun 1996 01:19:59 +0300 (EET DST)
From: Jukka Ukkonen <jau@jau.csc.fi>
Message-Id: <199606282219.BAA23320@jau.csc.fi>
Subject: physical memory addresses & memory locking...
To: hackers@freebsd.com
Date: Sat, 29 Jun 1996 01:19:58 +0300 (EET DST)
Latin-Date: Simbata XXIX Iunie a.d. MCMXCVI
Organization: Private person
Phone: +358-0-6215280 (home)
Content-Conversion: prohibited
X-Mailer: ELM [version 2.4 PL25+pgp]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


	Hello!

	In a previous message in which I primarily asked about something
	else I tried also to ask the following...

> 	What is the most reliable way to select a common memory address
> 	inside the 4.4BSD kernel for an object which has been mmap()ed
> 	as shared by multiple processes? I would like to make pick such
> 	an address so that any processes sharing the same object could
> 	be put sleeping on that very address until some other process
> 	sends a "go ahead" message to them. Maybe the macro vtophys()
> 	from machine/pmap.h would be OK?
> 	Oh yes, you may have guessed it. I am thinking about adding in
> 	the kernel support for semaphores settable by user processes,
> 	including the counting semaphore model from POSIX.4. POSIX.4
> 	message queues might come practically free with the semaphores,
> 	because I have POSIX.4 shared memory routines already which
> 	combined with the semaphores form the basis for the message
> 	queues anyway.
> 
> 	It would also be really interesting to know whether anyone from
> 	the mmap() people has been working on the new mlockall(2) and
> 	munlockall(2) stuff that was defined by POSIX.4.

	Does anyone have any idea about finding the kernel's internal
	memory addresses when one knows processes' memory addresses or
	does anyone have anything to say about the mlockall() stuff?


	Cheers,
		// jau
------
  /    Jukka A. Ukkonen,       FUNET / Centre for Scientific Computing
 /__   M.Sc. (sw-eng & cs)           Tel:   (Home&Fax) +358-0-6215280
   /   Internet: ukkonen@csc.fi                 (Work) +358-0-4573208
  v    Internet: jau@funet.fi                 (Mobile) +358-400-606671