Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Date: Sun, 21 Mar 1999 22:17:48 +0300 From: Egor Duda X-Mailer: The Bat! (v1.029) S/N A0F2A05A Reply-To: Egor Duda Organization: DEO Message-ID: <19929.990321@logos-m.ru> To: cygwin-developers AT sourceware DOT cygnus DOT com Subject: File System Extensions (FSEXT) for Cygwin Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! I've got an intention to implement "file system extensions" for cygwin in a way similar to their implementation in djgpp. Here're some design decisions i've made and some questions. 1. fsext is handled by dll, which should export a set of functions named fsext_initialize, fsext_open, fsext_creat, ... -- a set enough to handle all (or almost all) virtual functions of fhandler_base. 2. To install fsext there should be needed to specify it's name (and, possibly some additional parameters) in mount entry. Then, when dealing with posix path, which's mapped to fsext mount, cygwin will create special handler -- fhandler_fsext_driven to work with that file. For functions, which don't need file handle, such as "unlink", a call to dll should be done by function itself. 3. All fhandler_fsext_driven will share common "devn" -- FH_FSEXT. 4. All mount points are indexed with unique autonumbering long index, which's used in two ways -- as "unit" number for fhandler_fsext_driven and (optionally) for faster retrieval of mount info. 5. "fsext driven" mount point will also contain an array of FARPOC's -- array of "driver entry points". fhandler_fsext_driven will use it to call driver dll. Dll is loaded and array is init'ed "on demand" -- when application will try to use corresponding mount entry first time. Now questions: (Asterisk indicates my opinion) 1. Format of exported functions. They can either have similar format -- each of them got a pointer to structure (which is specific to fuction) -- the way MCI is implemented. Or all functions will have different parms and return types depending on function(*). 2. Custom data. "Driver Dll" may need to store some private data about each open file and for each driven mount point. where it should be stored? Either there can be pointers in mount_item and fhandler_fsext_driven, which are being supplied by dll on object initialization and given to it every time we call it(*), or it should be totally dll's problem? 3. Nonblocking operations. Should cygwin handle them by creating request queue and processing thread, or it should be done by driver(*)? 4. Driver initialization errors. Should we try to load and init driver until success(*), or it must be done once? 5. ASCII or Unicode. Which is better for supplying additional parameters to driver? 6. What should be returned as "win32 path" of emulated file? \dev\cygwin_fsext\\ (*). 7. Unloading driver. Should driver be freed when there're no open files on it, or there're no open files for some time interval, or there're no mount points driven by it(*)? 8. "mount" syscall. Perhaps it's specification should be changed to int mount (const char* type, const char* dir, int flags, void* data) where "type" points to driver dll name, and then "data" contains driver parameters or == NULL (or some special predefined value like "cygwin internal driver"), and then it's obvious cygwin mount and "data" contains win32 path. Hope to hear any comments. Code dealing with initialization and mounts has (in some extent) been written already, at least, I hope that most of further changes will be made in fhandler_fsext.{cc,h}. Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19