delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/10/18/04:54:28

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019