Re: Anybody working on removing sendmail from base?

[sander <sander@xxxxxxxxxxxxxxxxxxx>]

On Wed, 1 Oct 2003, Matthew Dillon wrote:

> :If a variant symlink uses an unset variuable then the lookup probably fails.
> :
> :I mean - you could probably do defaulting (say using ${VARNAME:default}
> :instead of ${VARNAME} or something), do we want this? For that matter,
> :*what* should the variant symlinks precicely do? Can $VARNAME contain
> :say "../lib/somepath/../lib2" ?
> :
> :> -Chris
> :
> :--
> :	Sander
>
>     A variant symlink would simply be a substitution.  I would even go as far
>     as to say that it would be a single-level, non-recursive substitution.
>     I don't see any particular reason to limit what the contents of the
>     variables can be.
>

By non-recursive you mean "$FOO containing $BAR will not cause the
contents of $BAR to looked at but the literal value '$BAR' to be used"? I
think this should be a requirement really. Restricting the variable to
not contain slashes or .. might be reasonable as a start and avoid some
problems.

>     I think the default idea is actually quite reasonable but I also see
>     there being several 'layers' of variable sets:  system level, user level,
>     and process level.  Maybe group-level would be good too but there are
>     no current kernel structures for that.
>
>     In the layered design the system level would contain system-wide
>     defaults, making those variables optional in the user and process layers.
>

One way to implement a layered design is to simply have init and login
(via the login class of the user or similar) to set the variables, which
would then apply to anything that doesn't explicitly change the variables.

>     The biggest question is how to store the variables.  Storing them in
>     kernel memory is my prefered solution so the substitutions can be done
>     simply, without adding any significant complexity to the kernel.
>

hash tables. unless use cases with lots of variability occur, you can just
COW most of these and hang off process struct. and hash tables work for
all 3 ways of the layered design:
	* no override, start by checking inits hash
	* hierarchical, process->user->init
	* non-layered

depends if layers are explicitly available as part of api. but having the
"system" or "user" environment be mutable could give truly bizzare
effects.

> 					-Matt
> 					Matthew Dillon
> 					<dillon@xxxxxxxxxxxxx>
>


	Sander

+++ Out of cheese error +++