DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=Gq5B+SpCxlbichGOxIrEP5OFjjUaO7ecz3+PoKvDvXzBY1/ka+P3V
	vnmPlX7cZHkFg+X4B3NZB/aahrJ44BnEKutLffDDCJoL1+NkL03luszHWwsv8Jd/
	TIOvUa80yLivRHaTp8fAXRbfF0vMJllbMD6rqG3n2CVON+R8I/pIcU=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Tue, 18 Jun 2013 12:17:06 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Cross-compiling Linux kernel
Message-ID: <20130618101706.GB27405@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <003401ce6b5d$f6ec87b0$e4c59710$%fedin@samsung.com> <51BF7465.2030104@users.sourceforge.net> <001301ce6bf0$ea4904a0$bedb0de0$%fedin@samsung.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <001301ce6bf0$ea4904a0$bedb0de0$%fedin@samsung.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Jun 18 10:56, Fedin Pavel wrote:
> [...]
>  P.S. I have got even more crazy idea, perhaps deserving a separate topic...
> BSD systems have Linux binary compatibility layer. Could we have one ?
> Technically this depends on ability to construct process image manually in
> Windows (*). Is it possible (using NT API of course) ? And, of course,
> someone needs lots of spare time to code this. :) OTOH, CoLinux already does
> this (yep, they are not 64-bit for now...), so perhaps there's no need to
> duplicate the job done.

Not in the Cygwin DLL.  As an extra DLL layer I don't have a problem
with that.

>  P.P.S. Perhaps the answer to (*) is NO, otherwise we would have fast
> fork()...

That's not quite correct.  The problem is not utilizing the native NT
functions to create a process image, the problem is that the Win32
libraries like advapi32, msvcrt, etc, which are directly or indirectly
loaded into a Cygwin process, are not capable to deal with a process
clone situation.  They were never designed this way and there's not much
chance they will ever get a revamp, just to allow Cygwin to create a
fast fork.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple