From owner-freebsd-current Wed Aug 28 13:15:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24609 for current-outgoing; Wed, 28 Aug 1996 13:15:51 -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 NAA24567 for ; Wed, 28 Aug 1996 13:15:28 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA27334; Wed, 28 Aug 1996 12:56:06 -0700 From: Terry Lambert Message-Id: <199608281956.MAA27334@phaeton.artisoft.com> Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 28 Aug 1996 12:56:05 -0700 (MST) Cc: jkh@time.cdrom.com, phk@critter.tfs.com, terry@lambert.org, stesin@gu.kiev.ua, angio@aros.net, squid-users@nlanr.net, current@freebsd.org In-Reply-To: <199608280329.MAA10965@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Aug 28, 96 12:59:41 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 > Time to take Terry up on his logicals concept. Anyone familiar enough with > the way that VMS handles/d these willing to talk for a while on it? I > seem to recall that you could create logicals on a system-wide basis as > well as per-session (or was that per-user?) > > There should be a way to integrate this with sysctl so that what are > currently sysctl variables become system-wide logicals with little or > no effective change, but the concept is extended to per-process group > (kinda like the environment), or summat similar. The tentative implementation I was favoring used the following model: 1) Process logical names o Hung of proc struct of current process o Inherited by reference ("copy on write") from parent process on fork() o Live across exec() o Replace getenv/setenv/putenv/unsetenv with library routines which interface to system calls; use of non-envp-based environment requires no changes to existing code linked shared. o A getenv of a name that is not in the process logical name table will inherit value from group, then system tables o A setenv/putenv of a name that exists in the group or system table will create a local entry that overrides via inheritance; the group/system table is not changable via setenv/putenv/unsetenv -- except as noted below o An unsetenv of an inherited value has no effect. You must use the LNM system interface to remove entries not in the local table o The POSIX interface is supported, but deprecated 2) Group logical names o Use process logical name table from controlling process of process group; no other related change necessary o Compare process ownership/credentials in modification case o Use same system call interface structure as that wrapped by getenv/setenv/putenv/unsetenv interface, where Process logical access through POSIX library wrappers imply user table o getenv/setenv/putenv/unsetenv will modify the process logical name table, even for the group leader; in the case of the group leader modifying their own table, the effect will be the same for the POSIX commands as for the process logical names, above. This is not the preferred interface for the group leader to set group logical name table values 3) System logical names o Uses process logical name table from init process (process ID 1). Since the init process normally operates without an environment (being hand-crafted), this is not antithetical to init o Compare ownership/process credentials in modification case (init runs with root credentials; therefore, effectively requires 'suser(cred) == TRUE') o Use same system call interface structure as that wrapped by getenv/setenv/putenv/unsetenv interface, where Process logical access through POSIX library wrappers imply user table o getenv/setenv/putenv/unsetenv will modify the process logical name table, even for the 'system leader'; in the case of the init process modifying its own table, the effect will be the same for the POSIX commands as for the process logical names, above. This is not the preferred interface for init to set system logical name table values What breaks: o The envp; it can be supported on a limited basis for compatability. POSIX exec envp compatability should be provided via library wrapper o An alternate implementation would be to dual map the table into the process address space and externally reference it via envp; this is necessary for binary compatability with statically linked programs, in any case. Because of this, the changeover would be most effective when the ELF binary changeover occurs, since the file magic number must change at that time, and the mapping can be handled via compatability calls for POSIX exec() implemented as a system call. What is enabled: o It is now possible to change the parent process's environment from the child. This has been a long desired feature o It is now possible to implement, simply and reliably, variant symbolic links. This has been a long desired feature o It is now possible for an execution class to impose path components based on per system emulation environment mechanisms. This resolves the ELF controversy, a well as the BSD compatability race with BSDI o It is possible to interface the init environment to replace the sysctl interface with a more generic mechanism. This is useful, both in moving to a central, and therefore simpler, contextual model, as well as allowing virtual system hosting to become more easily bound by moving sysctl references out of the system-wide scope of sysctl and into a per group scope for pseduo-group leaders other than init. This has profound implications for multiple hosting for ISP's, NSP's, and WSP's. I'd like to see Poul's stuff before I can comment on the merits of the model he has chosen, one way or the other. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.