Date: Thu, 27 Jun 1996 11:17:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: pechter@shell.monmouth.com, freebsd-hackers@FreeBSD.org Subject: Re: no subject (file transmission) Message-ID: <199606271817.LAA05396@phaeton.artisoft.com> In-Reply-To: <29794.835839033@time.cdrom.com> from "Jordan K. Hubbard" at Jun 26, 96 06:30:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'm a fan of OS/x and Pyramid dual universe stuff (which I will add to > > Freebsd -- think universe bsd and universe gnu/linux) and EVEN I think ONE > > Yuck! That was a total kludge, and Apollo's variant symlinks a far > more powerful/flexible approach (plus you don't have an extra > "universe" command, you just set environment variables - principle of > least surprise). Please don't perpetuate that system! :-( I have an implementation of variant symlinks. Only problem is that it changes the environment code to use logical name tables. This is a problem because: 1) Needs a system call entry point 2) getenv no longer returns pointer to environment buffer; it copies the variable out from kernel space to a size restricted (default: 4k) static buffer, and points to the buffer. Multiple calls must copy data locally to allow the pointers to remain usable. It's 4k because of the !$%@! xterm "TERMCAP" setting (also _POSIZ_ARGS_MAX from limits.h). 3) (char **environ) goes away. This is not really a big deal, since it is screwed up for 8 bit anyway (should be unsigned), but it can make use of execve(2), execle(3), and exect(3)... uh, difficult. There is also the issue of POSIX definition of environ. I suppose it could be maintained in parallel rather easily; there is a problem with the ** vs. *[] declaration of environ vs. envp, anyway, given ANSI C's stupid array-not-pointer-to-pointer semantics. Specification of a non-procedural environment access was a critically stupid thing for POSIX to do, since it prevents direct encapsulation (I suppose you could put it in another segment and dual map it, if you supported segement attributes in the kernel, which FreeBSD does not). The environment table is hung off the proc struct. Ideally, it would be copy on write. I didn't do that. There are three logical name tables: 1) Process: Hung off the proc struct of the current process. 2) Group: The LNT for the process which is the group leader. The process/group tables are the same thing for this process. 3) System: The LNT for the init process. Modifiable only by root. Getenv does a precedence inheritance of other environments: get from process LNT get from group LNT get from system LNT no such env Setenv/Putenv operates *only* on least environment: put to process LNT Unsetenv operates *only* on least environment: remove from process LNT It's a pretty obvious (and trivial) hack of moving the environment manipulation code into the kernel and making it take a pointer to an environment argument for most operations. The library routines become calls to the system call. The environment is copied on fork. Right now, the execve environment argument does nothing. Clearly, you could set/unset anything you wanted after the fork before the exec. Maybe a set function through the system call taking a list should be implemented later. Maybe execve(2) should become execve(3) with a call to the new list set function followed by a call to the exec(2) with the modified env. In any case, appropriate credentails will let you modifiy the process and group logical names from any process (non-root). This solves the "parent environment modification" problem. You can also, since you do not have to paw through a process data segment, access the contents of the environemnt for a process from the kernel. For instance in the namei symbolic link interpretation code to allow for variant symbolic links -- variant symlinks. Ideally, you would want to use logical name table manipulation in any new code to avoid the getenv() limitations, and to allow setenv/unsetenv type operations to operate on tables other than the process local table. Actually, the implementation is so trivial, I'm suprised no one has reimplemented it from my May 1994 description of my first implementation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606271817.LAA05396>