Date: Thu, 21 Oct 1999 13:12:22 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: DJ Delorie cc: djgpp-workers AT delorie DOT com Subject: Re: /dev/zero support In-Reply-To: <199910201432.KAA15018@envy.delorie.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.