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
Subject: Re: Egor's daemon
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: cygwin-patches AT cygwin DOT com
Cc: cygwin-developers AT cygwin DOT com
In-Reply-To: <20010912121322.A17887@redhat.com>
References: <1000295535 DOT 30404 DOT 67 DOT camel AT lifelesswks>
	<20010912115511 DOT A17668 AT redhat DOT com> <1000310370 DOT 30375 DOT 141 DOT camel AT lifelesswks>
	 <20010912121322 DOT A17887 AT redhat DOT com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.13 (Preview Release)
Date: 13 Sep 2001 08:25:07 +1000
Message-Id: <1000333508.31770.11.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 12 Sep 2001 22:11:58.0111 (UTC) FILETIME=[F0723AF0:01C13BD7]

On Thu, 2001-09-13 at 02:13, Christopher Faylor wrote:
> On Thu, Sep 13, 2001 at 01:59:29AM +1000, Robert Collins wrote:
> >On Thu, 2001-09-13 at 01:55, Christopher Faylor wrote:
> >> On Wed, Sep 12, 2001 at 09:52:14PM +1000, Robert Collins wrote:
> >> >Attached is a slightly reworked daemon that will not impact 95 in speed
> >> >(well at dll load for non-forked process's it will, but not after that
> >> >first request).
> >> >
> >> >Egors original message with changelogs describing this beast is
> >> >available
> >> >http://sources.redhat.com/ml/cygwin-patches/2001-q1/msg00260.html here.
> >> >
> >> >I've altered the layout slightly - I consider the daemon more core than
> >> >(say) cygcheck, so I placed it all in cygwin.
> >> 
> >> I don't recall the original layout but if it created a new directory then
> >> that is correct.  This shouldn't be in the cygwin directory.  I made a concerted
> >> effort to make it one directory per "thing" a while ago.  cygserver is another
> >> "thing".
> >
> >The original layout put it in utils, which didn't really fit either.
> >
> >Ok, I'll move it out. Do you wnat the shared functions (like
> >set_os_type) duplicated;put into a convenience library; or link straight
> >to the .o in the cygwin directory?
> 
> I'm not sure since set_os_type is undergoing a radical rewrite in 1.3.4.
> 
> It sounds like cygserver needs its own directory.
> 
> If it is using non-exported functions from cygwin then we have to design
> how the two entities communicate with each other.

It's more that until the two entities are in communication with each
other, they have to come to some common conclusions. Picking the OS
(what comms channels will be available) and security (attempt to
negotiate security, or don't bother) are the key things.

I had moved set_os_type to host_dependent.cc, which made sense to me,
and then just linked with host_dependent.o. Likewise for smallprint
(used by host_dependent.cc). That was it though.

Te point being that unlike (say) mount.exe, cygserver is actually part
of cygwin, so cannot be _fully_ dependent on cygwin1.dll. I do link
cygserver.exe to cygwin1.dll, so there's no reason that I cannot use
exlusively exported functions. (The cygwin1 loaded into cygservers
address space will behave as though there is no daemon).

Rob