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>