From owner-freebsd-current Thu Aug 29 11:09:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA23638 for current-outgoing; Thu, 29 Aug 1996 11:09:24 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA23616 for ; Thu, 29 Aug 1996 11:09:19 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA29057; Thu, 29 Aug 1996 10:55:14 -0700 From: Terry Lambert Message-Id: <199608291755.KAA29057@phaeton.artisoft.com> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: George.Scott@cc.monash.edu.au (George Scott) Date: Thu, 29 Aug 1996 10:55:14 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.org In-Reply-To: <199608290300.NAA08388@moa.cc.monash.edu.au> from "George Scott" at Aug 29, 96 01:00:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > The tentative implementation I was favoring used the following model: > > > > 1) Process logical names > > > > o Hung of proc struct of current process > > I'm not sure what this means! > > Could these logicals be accessed as a directory structure in procfs? > Something like /proc/127/env/SHELL which can be read, written and unlinked > to do getenv, setenv and unsetenv respectively for process 127? That's certianly one way of exporting per process information so it can be accessed and manipulated. > This would allow access to be controlled with the normal filesystem mode bits > and would save us from having to have yet another set of system calls to > implemented. The down side would be that having a procfs mounted would be > almost mandatory. The same argument gould be used to boundlessly expand the use of ioctl();s on the procfs, and throw out all the process tracing system calls, etc.. > While I'm at it, creating a /proc/127/parent as a link to /proc/125 (meaning > that pid 125 is the parent of pid 127) would allow neat things such as shell > scripts that could set their parents environment variables with a simple: > > echo "new value" >/proc/curproc/parent/env/PATH Yes; the main problem is establishing external control of the environment, however. Once that is done, then the door has been opened to a lot of uses and export implementations. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.