Re: FreeBSD malloc.c, -lmalloc, and squid.

> 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.