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
Message-ID: <08fa01c20fe2$e33b6020$6132bc3e@BABEL>
From: "Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
To: <cygwin-developers AT cygwin DOT com>
References: <072501c20fb8$8d16dc80$6132bc3e AT BABEL> <20020609163607 DOT GD26171 AT redhat DOT com>
Subject: Re: shm status
Date: Sun, 9 Jun 2002 19:24:25 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

"Christopher Faylor" <cgf AT redhat DOT com> wrote:
> Do we need a cygwin_internal interface?  How do OSes like linux do this?
>
> Maybe it makes sense to start exposing things via the /proc interface, if
that
> is the way linux does it.

AFAICT, Linux doesn't (currently?) offer the sysv ipc objects through the
/proc filesystem. You can get hold of current mmap'ed segments that way
(which may include shmat'ed segments) but there is no generic /proc/shm/...
or whatever.

It does give you access via the wondrously generic sysctl(2) interface; i.e.
by its equivalent of the cygwin_internal() i'face.

So my thoughts are that this is the Right Way to do it but . . . not right
now?

To begin with, I'll hack in the relevant interfaces to the cygserver daemon
to get a list of shmids and test this via a cygwin_internal() interface.
When it works (ha ha), I'll submit a patch but w/o the cygwin_internal()
interface.

At that stage we can re-discuss the /proc issue. Am I right in thinking that
there may be a re-think on the whole filesystem / mount implementation
coming up? i.e. to add a generic vfs interface (or the like)? If that's the
case, I'd prefer to hang back until that work happens. Of course, if that's
not really on the horizon yet, I could just go ahead w/ the current /proc
scheme.

Plausible?

// Conrad