Mail Archives: djgpp-workers/1999/10/21/07:30:58
On Wed, 20 Oct 1999, DJ Delorie wrote:
> Why does it matter what order the fsexts are run in? There should
> only be one fsext per open file descriptor anyway, and the open calls
> already support multiple fsexts.
You are assuming that an fsext hooks the handles only because it is
the same fsext that opened one of those handles. In that case, the
current support is mostly enough.
However, there are cases where an fsext hooks handles that it didn't
open itself, and the purpose of the hook is to do something other than
support a special device.
Consider the case of dbgcom.c: there the fsext watches handle-related
functions called from the application (the debugger) so that it could
distinguish between the handles owned by the debugger and those owned
by the debuggee (the latter need to be closed after the debuggee
exits, in order to support reinvocation of the debuggee without
terminating the debugging session).
Such an fsext usually needs to ``chain'' to the previous handler,
because it doesn't really implement a device or a filesystem. Right
now, after it did its thing, dbgcom.c sets an ``in-use'' flag and
calls the appropriate primitive directly. But that's awkward and
error-prone.
In other words, if we want fsext to be used for implementing some
general feature, rather than for supporting a single special device,
we need to be able to chain easily.
- Raw text -