From owner-freebsd-hackers Wed Jul 1 01:49:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA19003 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 01:49:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA18993 for ; Wed, 1 Jul 1998 01:49:56 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id KAA27088; Wed, 1 Jul 1998 10:49:55 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id KAA25121; Wed, 1 Jul 1998 10:49:55 +0200 (MET DST) Date: Wed, 1 Jul 1998 10:49:55 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807010849.KAA25121@surf.IAE.nl> To: jkh@time.cdrom.com Subject: Re: Variant Link implementation, continued X-Newsgroups: list.freebsd.hackers In-Reply-To: References: Organization: Internet Access Eindhoven, the Netherlands Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article 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