Anybody working on removing sendmail from base?

Sander Vesik sander at
Thu Oct 2 04:15:17 PDT 2003

Mike Porter <mupi at xxxxxxxxx> wrote:
> Hash: SHA1
> On Thursday 02 October 2003 12:35 am, Matthew Dillon wrote:
>>     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.
> the downside I see to useing kernel memory is hte question of just how much 
> memory the structures will take. In a system where 100 or 1000 processes 
> could be running at once, if each of those has a varsym table for it, and 
> there are 3 versions of perl and 3 versions of gcc installed, we are going to 
> be using a good chunk of  memory.  even if each layer only stores 'overrides' 
> from the previous layer, there may only be 5 users, and there would only be 
> one system are still talking a decent chunk of memory real estate.

It depends on how many processes hav different environment (for the purposes
of these tables) than their parents. Having the same one as the parent might
not cost any bytes.

> Also, isn't the idea of variant symlinks to make things dependent on the 
> environment?  It seems the idea you have discussed makes for having to use a 
> different way to set such things.  Question: can't we simply parse the 
> environment from namei() if a varsym is found, or would this incurr too great 
> a performance hit? (in other words, if we find a ${mta} we search the 
> enviroment for $MTA, which would have been set globally by /etc/rc.d/mail (or 
> overriden by .login or something), but if we don't find a ${ in the path, we 
> treat it normally?  Or am I missing something (which should be) obvious?

I would personaly prefer a different api from just making all envvars available
to namei. the unix environment is not a particularily nice thing, and you end up
jumping through extra hoops to make sure you don't have to reparse the environment
for each call. 

The downside is extra api, conceptualy having two environments and needing to 
augument shells to have an extra builtin. for me this is a reasonable tradeoff
- after all, most software will have been written for other OS-s and not know
about variance of symlinks anyways - but i guess others might not.

> mike
> Version: GnuPG v1.2.1 (FreeBSD)
> iD8DBQE/e+ZKY30jZzkECLcRAlWCAJ9j1VFAJoG419UgD9YV4Qj+qalOLgCgyI/l
> NBH1FiweSc1V8bkiNx/FdaA=
> =Wemm


+++ Out of cheese error +++

More information about the Kernel mailing list