Date: Wed, 1 Jul 1998 17:11:38 +0200 (MET DST) From: Willem Jan Withagen <wjw@surf.IAE.nl> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807011511.RAA08138@surf.IAE.nl> In-Reply-To: <13617.899298865@time.cdrom.com> from "Jordan K. Hubbard" at "Jul 1, 98 06:14:25 am"
next in thread | previous in thread | raw e-mail | index | archive | help
You ( Jordan K. Hubbard ) write:
=> > I've had some discussion with Terry about this, and one of the "options"
=> > would be to include the *env pointer into the u-area, such that we know
=> > where the user keeps his env.
=>
=> Well, just don't forget that the setenv() code in libc can change the
=> value of environ at any time with a realloc(), so if you're going
=> to copy it into the u_area you're also going to have to keep this copy
=> in sync unless you also had plans on replacing environ. :)
Terry suggested something to this end. Needless to say I share the :) in a
:{ sense. The reallocation would show due to the fact that not both *environ
pointer are equal. The problem might be that due to a realloc, the original
space no longer contains sensible ENV's, and the kernel chokes on that.
And as long as it would be in libc, then that might be a solution for
most decent programs. What is of more concern are static linked and/or
legacy programs.
=> > How hard is it to get to the user's data from within the kernel?
=> > And what about the copy penalty?
=>
=> It wouldn't be cheap, and I seriously pity the man who has to hack
=> this code into namei() without seriously perturbing its optimizations
=> for the "normal" case, but I think the speed/functionality tradeoffs
=> would be also be acceptable in the long run.
The serious penalty only comes when a variant-link element is found in that
specific path-element. Now the bad part is searching the user-space env
everytime a user access /usr/local in a full-path. I've even deleted a
optimsation which is IMHO not very efficient, but do obfuscate the code
very much. It all has to do with the special treatement of a path-component
of 1 char, just to save a malloc.
Namei in itself is relatively simple, it is lookup() where the real pain
to understand the code is. And sensibly trying to cache some of the lookups
is asking for even more trouble.
=> > Now the problem pointed out by Terry is that users are allowed to do nasty
=> > stuff to their environment, and in the process "invalidate" the u-area *env.
=>
=> Yeah, I think it'll be enough to worry about the sanctioned functions
=> for scribbling on *environ like setenv() and handle the people who are
=> deliberately pounding on *environ with some kind of reasonable range
=> checking.
Well IFF the enviroment has changed we could always fall back to default
behaviour. Which I would suggest is to eliminate the token, and thus
resulting in something like:
/usr/local -> /usr/.local.${OSVERSION}
have a few dirs .local.1.1.5 .local.2.2.6 .local.3.0 .local.4.0
(given, a little extreme range)
and then have a LINK .local. pointing to the lowest available denomenator
which would now be .local.1.1.5
=> > 1) 'legacy' programs have no knowledge about this stuff. So resolving
=> > links should make sense.
=>
=> Hmmm. readlink() would certainly do the expansion and prevent most
=> legacy programs from having to even know about environment variable
=> expansion in syminks, the question remaining as to what you do with
=> variable names which are invalid or non-existant. Pass through the
=> unexpanded token? Eliminate the token? Return NULL? :-)
Note that typo's in variant-linsk would be a problem for ALL programs,
legacy or not. Non existant names would translate to an empty string.
See above. with the addition that I would build it that there are some
systemwide settings to be always available through the sysctl stuff.
It would be a sort of hierachical namespace, like with the cpp includes.
It might even be sensible to create
${} links: search first ENV(), then sysctl
@{} links: only sysctl
Which reduces the legacy problem, slightly.....
I'll first create a standard set of sysctl-values to make the system more or
less usable, just to prove the concept (for those without Apollo history).
--WjW
--
Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606
P.O. 928, 5600 AX Eindhoven, The Netherlands
Full Internet connectivity for only fl 12.95 a month.
Call now, and login as 'new'.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807011511.RAA08138>