Mail Archives: djgpp-workers/1999/10/19/14:36:57
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/
- Raw text -