From owner-freebsd-hackers Sat Jul 4 13:28:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10197 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 13:28:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10186 for ; Sat, 4 Jul 1998 13:28:49 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id NAA09005; Sat, 4 Jul 1998 13:28:51 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd008992; Sat Jul 4 13:28:45 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA01169; Sat, 4 Jul 1998 13:28:44 -0700 (MST) From: Terry Lambert Message-Id: <199807042028.NAA01169@usr02.primenet.com> Subject: Re: Variant Link implementation, continued To: drosih@rpi.edu (Garance A Drosihn) Date: Sat, 4 Jul 1998 20:28:42 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Garance A Drosihn" at Jul 3, 98 01:02:23 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > To quote from the article written by Terry: > > For example, we could have made the /usr/lib/aout change appear > > to have zero impact. > > My guess is that no one is going to make the aout change appear to > have zero impact by assuming *every* *end-user* is individually > going to create symbolic links and set environment variables. Actually, that is not what I intended to happen. What I intended to happen was that the variable would be set in the process logical name table by the execuation class loader (which knows this information). If you attempt to execve(2) a program, and it is an a.out program, you get a.out variant link resoloution for it. So if I type "ldconfig", and "ldconfig" is an a,out program, then it will reference the files in /usr/lib -> /usr/libx/${#BINFORMAT} (or however the link is arranged). I chose the # as a namespace escape to place system variable into an environment because: 1) You can't create them with a leading '#', normally, in a shell. 2) You can't create them with a leading '#', normally, using the setenv(3)/putenv(3) interface to the libc. 3) Using: set > x ... ... . x Works as expected: the lines are treated as comments, and not attempted to be set, as use of "@" or some other prefix would be, and it is improper for programs to set into the system space. I expect the list of "system" valiables would either be a view onto the sysctl namespace (for the system logical name table, nominally belonging to the "init" process), or set per process group and per process as an override by the kernel (ie: for things like an a.out binary calling fork(2) then the child calling execve(2) to start a Linux branded ELF binary). In no case would this perticular soloution result in the end user setting anything themselves. > No, I > suspect some administrator or system-developer is the person making > the decision to create that particular symbolic link... And once > they do, then *every* end user had better not choose that particular > environment variable unless they fully understand how it's being used > for this symbolic link (even though ideally they wouldn't even know > the link exists). As you can see, for kernel set variables derived from information beyond the user's control, a namespace escape that in inaccessible to the standard environment interfaces (except "char **environ", and it's deprecated by the design) there is no danger. > Actually, though, I think that what I'm proposing is really just > an alternative to environment variables (not just "environment > variables for symbolic links", but "an alternative to environment > variables for holding configuration settings"). Perhaps that > wouldn't be too hard to do a simple cut of? I do not like the idea of inventing "yet another place to store configuration information"; I would *prefer* a soloution that unifies the environment. Since the kernel can't go to the envronment (if "char **environ" is *ever* extended), the environment can go to the kernel. This seems to be an obvious soloution to me, and it just happens to solve a slew of other problems (the "manipulate parent environmnet after a vfork" problem, the "manipulate an unrelated processes environment, for which you have the uid to do the job" problem -- ie: DISPLAY, among others, etc.). > To get the kernel to correctly *use* environment variables for > symbolic links is going to take some work (even if everyone agrees > it's the best of all ideas), and perhaps an alternative would be > less work to do. If so, I can get away with all this babbling > without irritating any person who is actually doing the useful > work on it... :-) I have implemented the code on an experimental basis. I am not terrifically happy with needing a new system call, nor am I happy with (basically) moving some of the existing libc code into the kernel; I'd prefer a lighter weight approach. I also have not resolved the exec(3) family's passing of "char **environ" to the execve(2) system call issues (in particular, my previous speculation about whther or not you are allowed to pass a NULL environment pointer, or must pass a NULL-valued real memory pointer remains unknown, so the "magic cookie" for the default "inherit from parent" is still not nailed down. But the code works. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message