Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <016701c0c8cd$37175220$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
References: <007a01c0c8ac$abc66550$0200a8c0 AT lifelesswks> <20010419080756 DOT B19483 AT redhat DOT com>
Subject: daemon ideas
Date: Thu, 19 Apr 2001 22:35:26 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 19 Apr 2001 12:27:56.0605 (UTC) FILETIME=[29C53ED0:01C0C8CC]


----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin-developers AT cygwin DOT com>
Sent: Thursday, April 19, 2001 10:07 PM
Subject: Re: gluttton for punishment


> On Thu, Apr 19, 2001 at 06:42:28PM +1000, Robert Collins wrote:
> >I wrote a bared bones SUS shmget, shmat ftok implementation for
cygwin.
> >
> >How much interest is there in seeing that fleshed out and submitted?
>
> I'd love to have a "native" shmget, etc. implementation.
>
> >Also are shared memory id's meant to be cross-process persistent?
>
> Yes.  That's why cygipc operates as a separate process.

Ok. Well I am happy to code up what I've got to a stable feature
complete level, but knowing egor's API for the server {(how to get it to
do things :] ) - egor is that formalised or just as it happened ?} would
potentially put design constraints on. I'll dig up that patch of egors
and have a looksee.

BTW I haven't looked into cygipc(so I can write a cygwin native
implementation), if there are special tricks in there to make it work
well and someone wants to spec those out for me, it might prevent dead
ends etc.

> >Chris - if the AT&T UWIN product supports shmget() then that's
probably
> >why they have a daemon component :]
>
> They use the daemon for other things too, like suid emulation, I
believe.
>
> I proposed a daemon implementation back in 1998, though.  I think that
> cygwin needs one, I am just reluctant to add YA configurable component
> to the distribution because my gluttony for punishment levels have
been
> maxed out.
>
> However, I do think we need to add a daemon.  We should add Egor's
daemon
> to the distribution in 1.3.1.
>
> cgf
>

WARNING. The rest of this email is written from a position of ignorance.
I'm really just blueskying to put my ideas about getting a reliable,
user-config-free server that is resilient to API changes without needing
userspace recompiles, but also doesn't bottleneck everything thru
cygwin1.dll

I can think of a few things that would be nice to see in a daemon.
1) Auto-start the daemon on win9x platforms when the first cygwin
process loads. The daemon then keeps running until killed. Goal: reduce
user configuration.
2) Consistency check the daemon (presumably it's a service?) config in
the registry on cygwin dll initialisation on NT platforms. If it's not
configured 'right' pop up a dialog that either offers to do it and
requests username & passwords etc or explains how to do it. Goal: reduce
user configuration.
3) Transparent calling mechanism. I.E. calling shmget() from a userland
program should use IPC of some sort to go direct to the running daemon.
Ideas for suitable IPC? Com comes to mind (out of process server only),
or rpc.
4) Either
* loosely coupled to cygwin1.dll, with cygwin1.dll able to operate
without the daemon (albiet with reduced capabilities) and version skew
resilient
or
* tightly coupled to cygwin1.dll preferrably launched from cygwin1.dll
(a la what rundll.exe does when it runs a .dll file). This would
eliminate the possibility for version skew. (nb: I don't mean
cygwin1.dll call createprocess("daemon.exe"..) I mean that the daemon is
_part_ of the cygwin1.dll and when launched is drawn from the same file.

I'm not a win32 expect, so feel free to laugh at these concepts :]

Rob