On 7 October 2011 16:18, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
On 7 October 2011 01:39, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... ?? {"","stWindow", &stWindow}, ?? {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
To check my understanding, do you mean #ioLoadFunction:From: as implemented in vm/sqNamedPrims.c, so the idea would be to treat the main VM as a module, and load functions that answer the argvec and envvec from that module?
Right. It is already treated as a module, so it is not new.
Thanks, I understand now.
I'll try this with OSPP when I get a chance. Meanwhile, if you want to take the lead on this issue to get the exported functions added to platforms code, that would be good.
I need to ensure that OSPP runs on trunk as well as oscog branches, which means that updates to all those branches would be best. But I suspect it may be possible to adopt a strategy of loading with ioLoadFunction, and if this fails, try a direct reference to the global variable (though I don't know if Carbon will allow this?).
Why? Why keeping workarounds?
Because for OSProcessPlugin I choose to maintain a certain level of backward compatibity and support for as many different VM projects as possible.
You lost me here. VM is evolving, things keep changing. Can you tell me any of the reason for keeping a freshly-built plugin to be compatible with 10-years old VMs? One could always use older version(s) of plugin which works with that VMs.. so, what is the problem?
Can you explain me , what is the benefits from staying compatible with dusty systems which, most probably, are used by 1% of users (if any)?
IMO, the purpose of plugin subsystem should be to serve as a way to customize the VM(s) for various kinds of distributions, but not as a way to ensure that something which was working 10 years ago, will keep working today without any changes.
You can introduce this logic right now in OSPP, without waiting updates to VM sources, since there are no any requirements to change VM code to be compatible. If those symbols are not exported by VM module, then plugin should behave as if platform have no support for this functionality, which is pretty fair (as you already told - some platforms/build configurations could simply not provide it). Its fine.
I will give it a try as soon as I have a chance (but I am traveling, so maybe not this weekend).
You fail primitive etc, and it is perfectly ok as to me. As soon as newer VMs will start exporting those symbols, an updated OSPP will be available to provide corresponding functionality.
It might be OK with you, but it is *not* OK with me.
Does that makes sense?
Yes, and thanks very much for your patience in explaining the export mechanism (sorry I was so dense before!).
You were not even close to testing my patience. Actually by saying "does it makes sense" i meant "does it sounds like a plan"? :)
Thanks, Dave