Cygdaemon - planning

Elfyn McBratney
Wed Jun 25 17:42:00 GMT 2003

I'm going over my work on the Cygwin daemon and concepts for future features and
I just wondered if anyone had any thoughts on these?

 - cygdaemon heap

   A linked node (struct) list of raw memory. I have an implementation working
   now used to store security attributes, daemon info and security (logon)
   tokens. As it's a memory/next type list(s) it's easily used, just by casting
   to and from different types.

 - suid/sgid

   With the above "heap" I have a half written suid/sgid implementation (from
   the Cygdaemon side of things). When a user executes a program/script/whatever,
   Cygwin will transport process info &c to the daemon using the layed out
   transports, and the daemon decides whether the request is cocher, if so it
   transports back a login token for the user. The login token is saved in the
   heap for future use.. I was thinking of the best way to interface with the
   daemon in cygwin. Most obvious places would be exec* and maybe fork.

 - ipc/sem/shm

   as the ipc and shm code is pretty much complete, all it needs is final
   touches and the implementation of semaphores, which is not that hard. I have
   shm{ctl,op,get} mostly complete but it's in a mess as I;ve not touched it in
   months. IMO, this should be the first thing to be worked on and exported.


I'm going to be working on this this week and next and hopefully will have the
ipc side of things finished enough (sem support anyway) by then, ready for the
Cygwin interface to be exported.

I have also changed things quite a lot. I've moved specific daemon code into a
new toplevel `cygdaemon' directory and kept/renamed the interface code in the
`cygwin' directory. Here's how things look locally on my branch

      ipc-utils/  - a few command line utilities (still a work in progress)
      moved to cygdaemon/modules/

If it's OK, could I start a branch for developement? After I've finished my work
on libgen and submitted the dang patch, of course. :-)


More information about the Cygwin-developers mailing list