From owner-freebsd-hackers Fri Feb 15 6:59:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.nentec.de (gate2.nentec.de [194.25.215.66]) by hub.freebsd.org (Postfix) with ESMTP id 939F237B402 for ; Fri, 15 Feb 2002 06:59:38 -0800 (PST) Received: from nenny.nentec.de (root@nenny.nentec.de [153.92.64.1]) by gate.nentec.de (8.9.3/8.9.3) with ESMTP id PAA09564; Fri, 15 Feb 2002 15:59:39 +0100 Received: from andromeda (andromeda [153.92.64.34]) by nenny.nentec.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g1FExYT08301; Fri, 15 Feb 2002 15:59:34 +0100 Message-ID: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3C6D137F.87FB3DC5@mindspring.com> Date: Fri, 15 Feb 2002 15:59:33 +0100 (MET) Reply-To: Andy Sporner Organization: NENTEC Netywerktechnologie GmbH From: Andy Sporner To: Terry Lambert , freebsd-hackers@freebsd.org Subject: Re: Reading userland environnement from the kernel X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Terry (and others!) You seem to know a lot about the kernel (as you always expand on my "Cliff Notes" versions of my answers). Can you give me any hints on the device driver question I posted a few days ago. There was a response, however I don't see how it applies for these reasons. 1. When the hardware (board) is inserted, but no kernel driver there are no failures. 2. When the hardware is installed with the minimal kernel driver the system locks. The minimal kernel driver only attaches some resources. 3. When doing the full initialization of the device (which works in NetBSD) there are also the SAME failures as doing no initialization at all of the hardware (as seen in the samples posted). 4. The device driver does not use MBUFS at all. Any ideas!?? :-) Thanks much in advance! Andy On 15-Feb-02 Terry Lambert wrote: > Sansonetti Laurent wrote: >> Hi hackers, >> >> Is there a way to read user-land environ(7) table from the kernel for a >> given process ? > > Yes and no, or we'd already have implemented variant > symbolic links. > > The problem is manifold: > > 1) The environment is pointed to by the environ ** > pointer in the user process. The location of > the environ ** pointer is not well known. > > 2) The environ ** value may be overridden by the user > program entirely, so the pages where the data lives > aren't where the are expected, so a saved pointer > to envp *[] at execve time is not a workaround > > 3) The envrion ** is require by POSUCKS (sometimes > spelled "POSIX"), so getting rid of it and making > the getenv/setenv/putenv/unsetenv functions use > a multiplex system call is not an option that > maintains POSIX compliance. > > 4) It's hard to satisfy #2 and #3 and maintain binary > compatability; the gross way you could do this is > to save two copies of environ **, the real one at > startup, and the shadow one called "environ **", > and then if the shadow does not match the real, > fall back to the historical behaviour. Synchornizing > means that you would need to know when the change > happens (not possible, unless you catch a write fault > and implicitly fix it up, like SVR4 does with page > zero pointer dereferences, unless you specifically > tune the kernel to fault fatally on them), or you > would have to reflect all kernel level changes into > the user space area shadow (expensive, but doable). > > 5) The execve() envp *[] passing is tricky, at best, > for a modified implementation, since you have to > read it back to pass it down. One option, which > fails POSIX again, is to pass the default in if > there is a NULL passed here, for an in kernel > implementation (actually, you don't have to pass > anything for the user environment, if the system > and group contain everything you care about). > > 6) You can also put the environ ** into user pages > (read only) that are also mapped into a pointer off > the proc structure (read/write), so that the kernel > changes are visible to user space. This makes it > so that environ ** is not writable, but it is OK > to read it, so a minimum number of changes are > required for system/group/user logical names. > > I run with a variant of #6 on one of my machines; I use the > same page I use for the environ ** for the pid, gid, and > other data to make them zero kernel overhead for getpid, > getppid, getgid, etc. -- basically, any system call that > only reads a small fixed sized data value. > > This still means that the environment is stored in the user > space process, but the current environ ** is always known > to the kernel, and if it needs to be modified, it takes a > system call. > > It's pretty cool: it lets me set the environment variables > for processes from other processes, and everyone inherits > from init's environment (system logical name table), the > process group leader's (if they aren't the leader themselves: > group logical name table) and then themselves, in increasing > priority, on getenv(). > > But of course, it violates the writability of **environ, > which POSUCKS wants, but I don't care (on that machine, > signals default to restarting system calls so that my > user space threads library is incredibly light weight, and > getting the one-close-destroys-all-locks-even-for-other-opens > behaviour is non-default, too... you have to fcntl(F_POSIX)). > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message