Date: Wed, 1 Jul 1998 10:49:55 +0200 (MET DST) From: Willem Jan Withagen <wjw@surf.IAE.nl> To: jkh@time.cdrom.com Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807010849.KAA25121@surf.IAE.nl> In-Reply-To: <list.freebsd.hackers#11724.899262125@time.cdrom.com> References: <list.freebsd.hackers#199806302303.XAA07485@digi.digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <list.freebsd.hackers#11724.899262125@time.cdrom.com> you write:
>> I have actual working code for this.
>> At the moment every variantlink gets replaced by '2.2.6', since that is my
>> current OS version.
>
>That's really cool! Apollo, here we come! ;-)
Just look for the Apollo FAQ and see why I'm chasing this one down.
:-D. I just loved my Domain babies.
[[ Now If could only read back my old Apollo-tars at 20 blocks = 10Kbyte. :-(
]]
>> - How can I efficiently obtain the value of a sysctl value?
>> And should they look like 'variant.name', or would/should a
>> variant link be able to look like:
>> kern.osrelease: 2.2.6-STABLE
>
>I would expect any sysctl expansion to just use the current names,
>e.g. /usr/tmp/${kern.osrelease} would pretty much do what you'd expect.
Oke, sounds sensible. Then you'd have a lot more "useless" values to scan
through do, while replacing. But it's a good start.
>> * An alternative would be: How do I obtain the environment of the
>> process using the link? (assuming it has nog messed with its
>> *env-pointer)
>
>Hooboy. That's the holy grail for variant symlink behavior, of
>course, but it's not information which is at all easy to get ahold of
>in the current implementation. :-(
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.
How hard is it to get to the user's data from within the kernel?
And what about the copy penalty?
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.
The solution would be to force a cleaner behaviour towards environment use.
I'm still trying to figure out how serious this is for what I'm trying to
make.
1) 'legacy' programs have no knowledge about this stuff. So resolving
links should make sense.
AND perhaps we would be just as happy, using the environment we
created at execve-time. Then the user can mess around all he/she
wants.
Then the u-area would have the keep 2 *env's, one to be manipulated
by the user. The other to keep pointing to the old structure.
2) ........
Terry had even more nice suggestions: like turning sysctl-name space into a
filesystem like thing. With rights and likes.
This will be too far out for my competence.......
--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?199807010849.KAA25121>