This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: baby steps vs overhaul


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

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <cygwin-patches@cygwin.com>; <cygwin-apps@cygwin.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]