This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project. See the Cygwin home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

File System Extensions (FSEXT) for Cygwin



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\<unit no>\<path within emulated fs> (*).

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@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19