Date: Wed, 20 Oct 1999 13:01:56 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Richard Dawe cc: djgpp-workers AT delorie DOT com Subject: Re: /dev/zero support In-Reply-To: <380B7B93.7C0BD749@tudor21.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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!