Date:	Mon, 18 Oct 1999 10:12:11 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Richard Dawe <richdawe AT bigfoot DOT com>
cc:	DJGPP workers <djgpp-workers AT delorie DOT com>
Subject:	Re: /dev/zero support
In-Reply-To:	<3808B8F0.754C8048@tudor21.net>
Message-ID:	<Pine.SUN.3.91.991018101138.3777B-100000@is>
MIME-Version:	1.0
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

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.

- Raw text -