Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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