Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <149701c19e79$4c168420$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
Subject: wacky idea #45
Date: Wed, 16 Jan 2002 21:33:53 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 16 Jan 2002 10:33:42.0907 (UTC) FILETIME=[4501ECB0:01C19E79]

Ok, its the time of year where I produce an idea, and get laughed
down...


I'd like to split the cygwin1.dll into a _real_ libc, libm, and possible
libpthread.

When? As time permits.
Why? Simplicity, efficiency.
Who? Whoever has time - I'll do some of it, but not at a rush!

I don't want to start working on something that has 0 chance of being
accepted, which is why the email and not a patch.

Cygwin1.dll does many things: It provides a C runtime library, it
provides 'kernel-space' calls (ie memory mapping is a kernel call)...

As I understand it, most of the C library is implemented in newlib, with
'kernel' calls sitting in cygwin. I.e. writeln() is in newlib, and uses
write(), which is also in newlib, but uses _write() (or something
similar) in cygwin to do the actual writing.

So my proposal is (over the long term, complete only after the next ABI
breakage (sidenote - should we have a list of things, like uid_t to
change when that occurs)):

1) Create a .dll, cygc-0.dll that contains the actual newlib libc code,
and links against cygwin1.dll.
2) Likewise for cygm-0.dll, and possibly cygpthread-0.dll.
3*) Where cygwin itself does not use a function, remove it from cygwin,
and turn it into a forwarded export from cygc-0.dll etc.
4) ? Do we want this step ? Get newlib building cygc-0.dll and
cygm-0.dll directly.

* = (backward compatability only, remove at the next ABI breakage)

There are a couple of reasons to do this.
a) A smaller .dll will load faster (and if done correctly, when an app
doesn't use libm, then libm won't load, likewise for pthread).
b) This will give greater clarity to what 'kernel' code, and whats
'user' code.
c) Static versions of the new libraries will be possible - by definition
they will not directly rely on the shared memory area. (But they'll
still need to link to cygwin1.dll, thus preventing anyone using cygwin
statically :] ).
d) Potentially, libc updates and libm updates can be disjointed from
cygwin1.dll updates.

Thoughts? Ridicule etc, all appreciated :}.


Rob