From owner-freebsd-current Wed Dec 2 17:13:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA03594 for freebsd-current-outgoing; Wed, 2 Dec 1998 17:13:16 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (ppp10.portal.net.au [202.12.71.110]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA03531 for ; Wed, 2 Dec 1998 17:13:03 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA01111; Wed, 2 Dec 1998 16:58:22 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812030058.QAA01111@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Robert Watson cc: Mike Smith , Andrzej Bialecki , Pascal Hofstee , Shawn Ramsey , oZZ!!! , current@FreeBSD.ORG Subject: Re: StarOffice-5.0... In-reply-to: Your message of "Wed, 02 Dec 1998 12:58:44 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Dec 1998 16:58:22 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sun, 29 Nov 1998, Mike Smith wrote: > > > > Yes, I've got the diffs against relatively fresh current. BTW, I asked > > > this question on -emulation, but got back a profound silence... Can we/ > > > should we incorporate this patch, and hide it under a kernel option, say > > > PROCFS_CMDLINE? The life would be soooo easier for people new to our linux > > > emulation... > > > > A couple of things: > > > > - If it's part of our emulation support, it should probably be the > > default (cringe). > > - Your patch doesn't preserve the remainder of the commandline > > arguments. Feel like fixing this and resubmitting it? > > I suppose there is no easy way for the procfs code to determine if the > relevant calls are coming from a linux emulated process or not? I don't think there's a uniquifier for the ABI mode in the proc structure, no. > If there > were, then the command line stuff could be made only to appear for Linux > processes. I'm guessing, however, that only the creds and arguments to > the vfs call make it that far down, and use of curproc seems > inappropriate? There's probably a pointer to the current process in the arguments. > Or, if loadable kernel modules (or whatever they are called today) could > add hook functions to the procfs module via some symbol or another, then > new items could be added based on context. That however, seems a little > too busy, given that stackable file systems don't work. :) Yeah. I was playing with a generic framework for componentised VFS', but I haven't had time to do much with it lately, and the proper semantics for things like locking were giving me some confusion. The real answer is a linux-procfs, which mounts on /compat/linux/procfs. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message