File System Extensions (FSEXT) for Cygwin

[DJ Delorie]

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

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.