delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2002/09/05/23:10:13

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: Thu, 5 Sep 2002 23:09:58 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Contemplating drastic change to mount handling
Message-ID: <20020906030958.GA27496@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
Mime-Version: 1.0
User-Agent: Mutt/1.4i

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.

/etc/fstab would be the same as it is on linux.  /etc/mtab would be a
binary (trie) representation of the mount table which could be mapped
into cygwin on the fly, eliminating the need to parse any options.

We'd still use the registry as a method for finding /etc but that would
be it.

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.

This thinking came about due to some late night dabbling with tries as a
method for scanning the mount table.  They hold great promise for this
since they are fast and handle maximal matching with ease.  But, then I
was wondering how I could easily store the trie in shared memory since
it relies on pointers and sizing a trie ahead of time essentially
requires building the trie first and then copying it into shared memory
since we don't currently have a convenient method for allocating shared
memory.

So, then it hit me that it would be nice to incur the overhead of
inserting stuff into the trie only once, when the mount command was
run.  So, every cygwin application would be able to access the trie
table just by loading a binary file into memory.

I'd also like to get rid of the cygwin method of doing things where if
you type "mount c:\foo /foo" then the mount is permanent.  I'd like to
make the mount only exist until the next umount or reboot, like UNIX.
That doesn't necessarily fall out of this scheme but I have a half
formed idea of how to handle this, too.

So, basically the "permanent" mounts would be whatever existed in
/etc/fstab, maybe with an auto field turned on.

I don't have this fully fleshed out in my mind yet but I thought I'd
type out my thoughts here.  This will undoubtedly cause a lot of
confusion since it is a drastic change.  I would feel a little uneasy
about making 'mount' impermanent but changing the registry keys doesn't
bother me at all.  I've been telling people not to directly manipulate
the registry 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.

Obviously not something for 1.3.13...

FYI,
cgf

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019