Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Aug 1996 12:56:05 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        msmith@atrad.adelaide.edu.au (Michael Smith)
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
Subject:   Re: FreeBSD malloc.c, -lmalloc, and squid.
Message-ID:  <199608281956.MAA27334@phaeton.artisoft.com>
In-Reply-To: <199608280329.MAA10965@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Aug 28, 96 12:59:41 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608281956.MAA27334>