DragonFly kernel List (threaded) for 2003-10
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Anybody working on removing sendmail from base?
: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 table..you are still talking a decent chunk of memory real estate.
I don't think this is an issue, there is no reason why we would actually
have to duplicate the syms for each process if they haven't changed.
: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?
:
:mike
The environment is in user space, which means that namei/lookup would
have to go accessing user memory, and the environment is also not
indexed so lookups would be slow. And, even worse, the environment
*IS* duplicated in each process.
-Matt
Matthew Dillon
<dillon@xxxxxxxxxxxxx>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]