Sender: richdawe AT bigfoot DOT com
Message-ID: <380B7B93.7C0BD749@tudor21.net>
Date: Mon, 18 Oct 1999 20:57:07 +0100
From: Richard Dawe <richdawe AT bigfoot DOT com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: /dev/zero support
References: <Pine DOT SUN DOT 3 DOT 91 DOT 991018101138 DOT 3777B-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> 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?

Well, it's a linked list, so you just need to create enough link
structures to point to all the built-in functions, and then join them
together with next pointers.

I did think about /dev/mem, but I wasn't quite sure how to implement this.
What does it normally do? How would selectors be taken into account? Would
/dev/mem only access the processes's memory space? Or is it the whole of
logical memory? How about /dev/kmem?

I had a crazy idea about implementing lots of Linux /dev equivalents.
Another idea was /proc, but since we have only process, I guess there's
not a lot of point ;) Unless there's some way you can assign TSRs process
IDs too?

> 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.

I'm not sure I like the sound of this priority indicator - it sounds a bit
too arbitrary. I'm sure it would be abused, not maliciously, just because
it is easy to assume your module is the most important ;) 

> 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.

This sounds better. The question now is what information needs to be
returned by the enumeration function. Here's what I can think of right
now:

- the file paths handled by the FSEXT, e.g. /dev/mailslot/* for LAN
manager mailslots;

- what __FSEXT_* codes the FSEXT supports, e.g. __FSEXT_read;

- a version number;

- whether it can be overriden - again I think this can be abused.

I'm sure this list is incomplete. 

> 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.

You mean a function similar to __FSEXT_call_open_handlers()? This function
looks generic enough to be used for _all_ FSEXT operations, since you pass
the __FSEXT_* codes as the first argument. Maybe it should be renamed to
__FSEXT_call_handlers()? It gets called in src/libc/dos/io/_open.c.

> It would be nice if, as part of your work, you could extend the FSEXT
> infrastructure to address the above issues.

That seems like a good idea - I'll do it at the same time.

Bye,

-- 
Richard Dawe
richdawe AT bigfoot DOT com ICQ 47595498 http://www.bigfoot.com/~richdawe/