Cygdaemon - planning

Elfyn McBratney
Wed Jul 2 10:33:00 GMT 2003

On Wed, 2 Jul 2003, Charles Wilson wrote:

> > I was wondering if it would make sense for the DLL to autoimport
> > whatever it needs from cygserver.exe rather than build functionality
> > into cygwin1.dll?  I think that I would have to release a new version of
> > binutils which allows this, since autoimporting from a DLL wasn't
> > allowed in binutils into lately, but it seems like a fairly nice way of
> > localizing all of the cygserver functionality in cygserver itself.  If
> > cygserver wasn't somewhere in the path, cygwin1.dll wouldn't use it.
> > Otherwise, it would, when the CYGWIN option was set.
> Well, I dunno about this.  It makes sense in theory -- but what if I
> have a non-cygserver application that depends on symbols that are now
> available only from cygserver.exe?
> I'm thinking specifically of ipc-daemon2, libcygipc, and ftok().  (It
> may be that ftok() is the only such symbol that may be affected by this
> plan, I don't know).
> In any event, whatever you do, please make sure that ftok(), at least,
> stays in cygwin1.dll and doesn't get "moved" to cygserver.exe.

IMO, now that ftok has moved from cygserver to the DLL it'd be silly to just
move it back again. Without looking at the code (and I don't want to do that ;-)
I'm guessing ftok() is cygipc's only dependency?

I plan to keep *only* interface code for cygserver in winsup/cygwin , if CGF
agrees that is. And everything else goes into winsup/cygserver. In this case
{ipc,sem,shm}.cc will be kept where they are (with ftok in

Now that we have shm support, perhaps now would be a good time to implement a
'shm' filesystem type, like linux does. Or have something like this ready for
1.5.2 . Thoughts?


More information about the Cygwin-developers mailing list