Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <010701c14a10$96c0e280$01000001@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
Cc: "Ronald Landheer" <info AT rlsystems DOT net>
References: <00e301c14a0a$3090f820$01000001 AT lifelesswks> <20010930202016 DOT B3722 AT redhat DOT com>
Subject: Re: baby steps vs overhaul
Date: Mon, 1 Oct 2001 10:32:44 +1000
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 01 Oct 2001 00:39:50.0729 (UTC) FILETIME=[945FCB90:01C14A11]

Ok, cc'ing Ronald. (will his posts get rejected?)

----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin-patches AT cygwin DOT com>; <cygwin-apps AT cygwin DOT com>
Sent: Monday, October 01, 2001 10:20 AM
Subject: Re: baby steps vs overhaul


> On Mon, Oct 01, 2001 at 09:46:55AM +1000, Robert Collins wrote:
> All that is required is for someone to submit a patch for
consideration.
> I certainly will consider a patch that advances an architectural goal
but
> I'm not going to accept something that breaks cygwin for any length of
time.

Abso-bloody-lutely!. I guess I didn't really make that clear. Done right
this approach _never_ breaks cygwin at all. And if a mistake happens -
which is what I meant by *hiccup* - there is only _one_ patch to
roll-back.

> I'd like to also be convinced that anyone submitting patches is going
to
> be around for the long haul.  I accepted, much against my better
judgement,
> patches from people who were going to add pthreads to cygwin and make
it
> thread safe.  As we all know, the patches were incomplete and the
people
> disappeared.  I'm not going to repeat that mistake again

I presume this was the code I have replaced?

> >2) Add the capability to manipulate the mount table with associated
> >fshandlers. (this involves altering mount.exe as well.)
>
> I don't know why this would involve mount.  Except for one specific
case
> for the cygdrive stuff, mount just calls setmntent/getmntent/endmntent
> to display information.  If we have to do something different from
that
> then, IMO, the model is wrong.

Ok, here's the goal, I'm happy to hear of a different approach.
$ mount -t devfs /dev
and optionally
$ mount -t win32 /usr/bin options=win32path=E:\\cygwin\\bin
or in other words, just like linux.

I really cannot see _any_ correct way way to achieve this without
altering setmntent and therefore mount.exe. However, the linux API can
provide the exact API interface to use. (This is what you told me to go
and do for the UMSDOS stuff I was working on).
http://sources.redhat.com/ml/cygwin-apps/2001-06/msg00104.html

> However, your points are well taken.  Thank you for enumerating the
ways
> that an incremental approach to this design could be taken.

My pleasure. I'm always keen to avoid wasted work, and that is the risk
when starting an architectural change (as opposed to simply adding a new
fhandler for example).

> I want to also point out the fact that Cygwin is a product that is
used
> and sold by Red Hat.  We can't afford (literally) to keep it in an
unstable
> state for too long.

IMO it should never be unstable. Thats the point of developing off-HEAD.

Rob