This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: MSYS mode (continue)
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 30 Jul 2013 11:43:49 -0400
- Subject: Re: MSYS mode (continue)
- References: <51F68BED dot 5010506 at gmail dot com> <20130729154725 dot GD4166 at calimero dot vinschen dot de> <51F70C96 dot 8040808 at gmail dot com> <20130730090428 dot GL4166 at calimero dot vinschen dot de> <CABEPuQJxfk42ApfWi4dpqxO_6WAqko_+eNprHs=unbkWdA5H+A at mail dot gmail dot com> <20130730094702 dot GN4166 at calimero dot vinschen dot de> <CABEPuQL_fRE1T2XQf0UQNbiybyWQ-eWO5j92Hu0P1gBkA+k1hQ at mail dot gmail dot com> <20130730103350 dot GO4166 at calimero dot vinschen dot de> <CABEPuQLm6StPQ2tZtBZ40W53O8=MukV=5=S_xMoqbmy8jD7cJA at mail dot gmail dot com> <20130730145533 dot GA3652 at ednor dot casa dot cgf dot cx>
- Reply-to: cygwin-developers at cygwin dot com
On Tue, Jul 30, 2013 at 10:55:33AM -0400, Christopher Faylor wrote:
>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
I just implemented some of this and I'm wondering if we might need
some way of controlling the flow on entry to a function and on exit.
So maybe the above could be implemented as:
CO_UNAME_ENTRY
CO_UNAME_EXIT
but that might be overkill. It wouldn't necessarily make sense for
CO_SPAWN either.
cgf