From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6945 invoked by alias); 11 Jul 2013 11:17:48 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 6933 invoked by uid 89); 11 Jul 2013 11:17:48 -0000 X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 11 Jul 2013 11:17:47 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id E04A15200AD; Thu, 11 Jul 2013 13:17:44 +0200 (CEST) Date: Thu, 11 Jul 2013 11:17:00 -0000 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: MSYS mode (continue) Message-ID: <20130711111744.GG15346@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20130704091632.GM5118@calimero.vinschen.de> <20130704101046.GN5118@calimero.vinschen.de> <20130704103708.GA12995@calimero.vinschen.de> <20130704121617.GC12995@calimero.vinschen.de> <20130704163612.GA4729@ednor.casa.cgf.cx> <20130705090704.GB4009@calimero.vinschen.de> <20130705164230.GA7282@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130705164230.GA7282@ednor.casa.cgf.cx> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-07/txt/msg00003.txt.bz2 On Jul 5 12:42, Christopher Faylor wrote: > On Fri, Jul 05, 2013 at 11:07:04AM +0200, Corinna Vinschen wrote: > >I don't think hooks make sense for such simple, nonintrusive stuff. > >This may be different for bigger things like the weird "copy symlinks" > >stuff, of course. > > > >Also, you didn't so far define how these hooks are supposed to work. > >A detailed description of your idea would be useful for the discussion. > > http://cygwin.com/ml/cygwin/2013-06/msg00515.html > > I thought it was clear that this would be a general mechanism which > could be used to modify Cygwin's behavior. > > So, in this scenario, you would: > > callout (CO_UNAME, &name); > > We would provide a cygwin_internal method for setting up the callout > hook. If that wasn't set up then obviously callout would be a no-op. > > I don't think that it makes sense for there to be two mechanisms to > accomplish the goal of allowing another DLL to modify Cygwin's behavior. > > Obviously a MSYS helper DLL would have to do the setup early, maybe > in its DLL initialization. The hooking itself is the lesser problem. What I'm rather wondering about is how the MSYS helper DLL comes into action. Ideally, MSYS executables would actually be Cygwin executables, linked against the Cygwin DLL. The advantage being that the executable could run in an MSYS and a Cygwin environment, whatever it happens to be dropped into. The MSYS DLL could be loaded from an MSYS specific crt0.o, which tries to load the MSYS DLL dynamically. Either loading the MSYS DLL works or it doesn't, but if it works, it could just call cygwin_internal in it's dll_entry function to set up the hooking mechanism. If it fails, the executable works as a plain Cygwin executable. Alternatively, MSYS crt0.o itself provides all the necessary functionality, which might be a lot easier to implement. It could call cygwin_internal and provide the necessary callbacks and it would be linked against the Cygwin DLL "just so". Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat