Mail Archives: cygwin-developers/1999/03/21/19:27:58
> 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.
- Raw text -