Mail Archives: djgpp-workers/1999/10/20/07:30:47
On Mon, 18 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.
Sure, it's not rocket science, it just has to be done. In the current
library code, this isn't happening. An extension that hooks a service
needs to work hard to make sure other extensions get to see the
service. Normally, if the extension rejects the call, it goes out to
DOS, and that's it.
> 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 believe these questions will have to be addressed in the context of
a concrete application. IMHO, it doesn't make sense to design a
feature if we have no clear idea how it might be used. The problems
you raise are solvable, but a good solution needs to have an
application in mind.
> 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 ;)
/proc does make sense, provided that you make it possible to
communicate between parent and child processes, or between two
programs running in different VMs, like on Windows.
> 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 ;)
If we design several standard priorities for extensions that are parts
of libraries, and document those priorities as "not for application
use", we can expect well-behaved libraries and applications to play by
the rules.
Abusers will be punished by having bad things happening to them.
This is so even today. For example, if an application issues a
literal INT 21h instruction instead of going through __dpmi_int, it
can crash certain cases which __dpmi_int handles gracefully.
> - 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'd add an indicator of whether the extension is part of application
or library code (that's the same priority in disguise). I expect this
to be the most important indicator of where to plug my extension in.
And we need a function to allow an extension to put itself in a
certain place of the chain, once it figured out what that place is,
given the output of the enumeration function. Something like
__FSEXT_set_function_after or some such.
> I'm sure this list is incomplete.
Let's get this rolling, and add whatever is missing as the needs
arise.
> > 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
Yes, something like that. Except that we need to make it call the
handlers in an order that can be controlled. If the way to control
the order is implemented by letting extensions plug themselves into
any place of the chain, then this aspect is solved.
> > 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.
Great!
- Raw text -