Mail Archives: cygwin-developers/1999/03/21/16:04:44
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 AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
- Raw text -