This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MSYS mode (continue)


On Tue, Jul 30, 2013 at 02:59:40PM +0400, Alexey Pavlov wrote:
>We need to determine places where you need to create hooks in
>Cygwin.dll and also prototypes for external functions (input and
>output arguments). Msys mode only change functions for non-Cygwin
>applications and in this case where it can be handled? In cygwin.dll
>or in msys.dll?

This is the outstanding question for the last month or so.

>For example, when we pass arguments to new process we determine in
>Cygwin is new process depends on cygwin.dll or not and make decision
>about changing arguments. If new process is non-cygwin then we try to
>change arguments else we leave them as is. If we need do implement
>decision logic in msys.dll then we need to rewrite many code. But if
>we implement it in Cygwin dll then it was simple like this:

No.  In the spawn function, you have something like:

  if (!callout (CO_SPAWN, mode, &argv, &argc))
    ...

And a DLL which has been preloaded and registered with cygwin1.dll will
modify the arguments as needed.

Either that or, the other proposal is that MSYS could just use LD_PRELOAD
but, as attractive as the notion of not modifying Cygwin at all might be,
it would mean that the MSYS dll would have to do a lot more work for
the above scenario because it would have to emulate a lot of what Cygwin
does to emulate exec/spawn.

So, in the interests of moving this discussion along, here is a more
fleshed out proposal:

Any helper DLL would be registered using a CYGWIN environment variable
preload keyword:

set CYGWIN=preload:msys.dll

An error will be issued if Cygwin can't find the preload dll.

The DLL will register callouts via:

cygwin_internal (CW_CALLOUT, function_which_handles_callouts);

Callout		Arguments
CO_SPAWN	mode (value), argv (reference), argc (reference)
CO_UNAME	utsname (reference)
CO_ENV		envp (reference)
CO_SYMLINK	is_native_symlink (value), oldpath (reference), newpath (reference)*
CW_MALLOC	Amount of cygheap memory to allocate

*Choosing where to call this might be tricky.  I don't see any reason
why MSYS shouldn't avail itself of the new native symlinks if they
can be created.  Otherwise, symlink would have to be short-circuited
in some cases so maybe we need to check the return value of the callout
function:

  ...
  switch (callout (CW_SYMLINK, is_native_symlink, &oldpath, &newpath))
    {
    case CO_R_KEEP_GOING:
      break;
    case CO_R_SHORT_CIRCUIT:
      return 0;
    case CO_R_ERR:
      return -1;
    }
  ...

The callout function will look something like:

enum callout_return
callout (enum callout co, ...)
{
  if (!callout_func)
    return CO_R_KEEP_GOING;
  va_list ap;
  va_start (ap, co);
  return callout_func (co, ap);
}

(I have to think about the most efficient way to implement this)

What other CO_* values are needed?

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]