Re: Contemplating drastic change to mount handling

[Christopher Faylor <cgf at redhat dot com>]

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