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
Date: Fri, 6 Sep 2002 23:01:45 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Contemplating drastic change to mount handling
Message-ID: <20020907030145.GA28798@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20020906030958 DOT GA27496 AT redhat DOT com> <3D78A504 DOT 67C2206E AT yahoo DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D78A504.67C2206E@yahoo.com>
User-Agent: Mutt/1.4i

On Fri, Sep 06, 2002 at 08:52:20AM -0400, Earnie Boyd wrote:
>Christopher Faylor wrote:
>> 
>> I'm thinking of making a drastic change to mount handling.
>> 
>> Basically, I'd like to eliminate most of the registry and move mount
>> handling into two files: /etc/fstab and /etc/mtab.
>> 
>
>Seems familiar.  I seem to remember discussing this with you in the
>previous century.

I do remember discussing moving to a /etc/fstab mechanism.  I was
probably adamantly against it too.  I still feel a little ambivalent
but reading recent cygwin at cygwin messages have made it really obvious
how odd cygwin's mount table is wrt linux.

>> We'd still use the registry as a method for finding /etc but that would
>> be it.
>
>You could take the approach I did for MSYS and base the root / mount
>point on the parent of the directory containing the cygwin1.dll.  It
>eliminates the need for the registry entry.  The /bin mount point is the
>directory containing the cygwin1.dll.  Both / and /bin and noumount. 
>And while you're at it, /bin should be cygexec.  With MSYS I also made
>/usr equivalent to / but that could be debatable for Cygwin and don't
>have preconceived advice for it's usefulness for Cygwin.

Hmm.  I have to think about this.  I don't know if I want to hardwire the
fact that /etc == /bin/../etc into cygwin.

OTOH, it would be sort of cool to actually append the mount table to the
cygwin DLL itself.  Probably impossible but it would ensure that the mount
table was always available.

>> In this scheme, /etc/mtab would be different than it usually is on unix,
>> so maybe it should actually be called something like /etc/bmtab.  It
>> would be manipulated only by mount.
>
>Well, you could instead use /proc/mtab.  This protects it from being
>modified by some outside source.

It has to be an actual file, though, for mmap to work.

>Changes are always interesting.  There will always be the extraneous
>existing documentation, especially those not controlled by Cygwin that
>will cause much grief.

Oh yes.  People will be talking about this change for years.

>> Oh, and the other thing that would be nice to come out of all this would
>> be a generic library that could be linked into other applications (like
>> cygcheck and setup) which could manipulate the mount table.
>
>That obviously would be good, would it be mtab it reads or fstab?

mount -a

reads /etc/fstab to produce /etc/[b]mtab.  /etc/bmtab is assumed to
be mounted "on reboot".  This is another variation from UNIX but I
don't think we want to set up a /etc/rc.d structure in cygwin quite
yet, although it has been suggested.

>You haven't mentioned though the /cygdrive implementation.  For MSYS I
>removed the /cygdrive and added automounts for each drive letter.

/cygdrive stays the same but, with a trie implementation, it would live
in the mount table along with everything else.  In fact, I put
everything in the table.  I put a: - c:, '\\', '//', '/cygdrive',
'/cygdrive/a' - '/cygdrive/z'.  Then everything gets its own mount table
entry.  Parsing is a snap.

>> Obviously not something for 1.3.13...
>
>Yea, more like something for 2.0.0 even though the ABI is still backward
>compatible.

I'm not contemplating ABI changes.  It's barely possible that I could do
this without anyone really noticing.  I could just keep the registry
around.  It is really orthogonal to the concept of the binary trie
stuff.  In this scenario, you could actually export the registry
as /proc/mounts.

cgf