Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Fri, 26 Jul 2002 14:20:06 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: cgf's sandbox
Message-ID: <20020726182006.GA485@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20020726015300 DOT GA11832 AT redhat DOT com> <003901c234cd$509446f0$0100a8c0 AT atomice DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <003901c234cd$509446f0$0100a8c0@atomice.net>
User-Agent: Mutt/1.3.23.1i

On Fri, Jul 26, 2002 at 06:53:14PM +0100, Chris January wrote:
>> I promised Christopher January that I'd try to implement a cmdline
>> method for pinfo and I've got something in my sandbox that seems to work
>> ok.  It contacts the other process and says "give me your command line"
>> so there is no use of shared memory.
>Thanks for taking the time to do this.
>
>>
>> I implemented /proc/cmdline as a proof of concept and it seems to
>> work well.
>>
>> I can extend this mechanism to allowing /proc/pid/fd/n, too.
>That would be good. Someone wanted lsof to work on Cygwin - adding
>/proc/<pid>/fd should help a lot.

Right, that was what prompted me to work on this a little more.

>>
>> I have a few more things to tweak and then I can check this in.
>>
>> My sandbox also has the beginnings of a mount table generalization that
>> should allow /proc and /dev to be mounted as special filesystems, too.
>> That is in a much earlier stage of development, though.  I'm not entirely
>> satisfied with it yet.
>Perhaps this would be a good time for the implementation details for this
>could be opened up for wider discussion in case anyone has any comments?

There are too many rough spots for that yet.  I was just mentioning this
so that people would be aware.  Hopefully no one else will be tromping in
the mount code for a couple of weeks.

>One question - for some of the items in /proc/<pid> I have native (NT only)
>implementations as well (e.g. I have a native routine that gets the command
>line of a program, another that lists open files). What are peoples views on
>adding support for native processes to /proc? (These would also show up in
>ps, etc.) I was thinking of using an environment variable to switch between
>Cygwin processes only and all processes (like the -W switch of ps).

I dunno.  I have mixed feelings.  It's easy enough to get command line info
on NT systems, and maybe even 9x systems but once we expose these then will
people be expecting "kill" to work on the pid?  I guess if it is controlled
by a CYGWIN=procnative (or whatever) then the user would have made a conscious
decision to use this.  I kinda hate growing the dll to accommodate this but
it probably would be a nice feature.

cgf