Date: Mon, 18 Oct 1999 10:12:11 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Richard Dawe cc: DJGPP workers Subject: Re: /dev/zero support In-Reply-To: <3808B8F0.754C8048@tudor21.net> 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 Sat, 16 Oct 1999, Richard Dawe wrote: > I think /dev/zero support code could be linked in automatically by having > the FSEXT list point at the relevant FSEXT function This is okay for a single supported extension, like /dev/zero. But what if we'd want to add support for another similar extension, like /dev/mem? In other words, we need a way for an FSEXT to hook the services in a controlled order. One way of doing this would be to add a priority indicator to each FSEXT, and make them be invoked in the order of their priority rather than in the order they installed themselves. Another possibility would be to add a function that enumerates the extensions that hooked a service, and provide a way for an extension to plug itself into the chain at a certain place, based on the info returned by the enumeration function. We also need an easy way for an FSEXT to ``chain'' to the previous handler. One way of doing this would be to arrange for the low-level library functions that support FSEXT, like _open, _read, etc., to call all the handlers one by one, until one of them returns a special value. > In that case I will use my original FSEXT approach, unless there are any > more thoughts. It would be nice if, as part of your work, you could extend the FSEXT infrastructure to address the above issues.