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 19:27:38 -0500 Message-Id: <199903220027.TAA13581@envy.delorie.com> From: DJ Delorie To: deo AT logos-m DOT ru CC: cygwin-developers AT sourceware DOT cygnus DOT com In-reply-to: <19929.990321@logos-m.ru> (message from Egor Duda on Sun, 21 Mar 1999 22:17:48 +0300) Subject: Re: File System Extensions (FSEXT) for Cygwin References: <19929 DOT 990321 AT logos-m DOT ru> > 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(*). There should be some way of letting the fsext allocate a "handle" that cygwin must pass to all future calls. That way, the fsext could malloc a structure or something, pass the pointer back, and get ready access to that structure whenever it's called. > 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? DLL's problem, but cygwin needs to pass the dll *something* to help it figure out *which* data it should refer to. > 3. Nonblocking operations. > Should cygwin handle them by creating request queue and processing > thread, or it should be done by driver(*)? DLL's problem. The only time cygwin needs to help, I think, is if you want to do asynchronous notification of available data via signals. select() will need a hook into the fsext also. > 4. Driver initialization errors. > Should we try to load and init driver until success(*), or it must > be done once? Load and init once per process probably. If it fails, it fails. It will probably be easier to retry loading for each call, since that doesn't make you remember if it should be tried or not. > 5. ASCII or Unicode. > Which is better for supplying additional parameters to driver? ASCII, since that's what we use now, and what POSIX uses. > 6. What should be returned as "win32 path" of emulated file? > \dev\cygwin_fsext\\ (*). There should be no such thing, since there is no win32 path to convert to or from. Conversion only makes sense when win32 programs could use the path. In this case, they can't, so the function should fail to prevent other more subtle problems. > 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(*)? Maybe when there's no processes who had used in still running. > 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. Traditionally, mount() takes a string for the parameters, and it's up to the fs driver to interpret them. > 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}. If you need a good choice for an example, try making a registry file system. I've heard people asking for this before.