> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Kevin Lawton
> Sent: Wednesday, August 02, 2000 12:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: plex86.conf script file ideas
>
>
> Drew Northup wrote:
>
> > Sorry to tell you Kev, but you seem to have forgotten that we
> will have to
> > write it 20 different ways--script or no script. For example, what is
> > handled by insmod in LINUX is done by a kernel32 library call
> in Win32, and
> > so on, and so forth. Many of the things that you have
> mentioned seem to me
> > as if they would be better handled by system() calls anyway.
> Since we will
> > have to write up different sections for different OS's in any
> case, why not
> > put those sections to some use here.
>
> You are talking about something different. That kind of stuff is
> hidden by code abstraction. What I'm talking about is at the
> script file level. You may have one routine which initializes
> the CPU to a certain state, and which you pass a filename
> of an image file. This would logically be a function
> in a scripting language. If you want to control behaviour
> of downstream script code with having to continually
> edit it, that would necessitate implementing variables.
> And if-then-else clauses, and loops, and...
Maybe I wasn't entirely clear here either ;-). What I mean is that only so
much of what we wish to do on init can be done from the command prompt over
several host OS's. As for my opinions on other stuff (what happens after
init......) I can, if you wish, re-explain that in some other manner.
>
> There are some other features that would be damn helpful.
> It would be helpful to do something like this. Load a
> user module at the command prompt. Run some tests.
> Be able to init it or reset it at will. Unload the module,
> reload a different version of it, and retry some tests.
> All on the fly, interactively. You just can't do this
> with a KISS script.
Yes..., this is very true. But, on the flip side, how do we wish to
accomplish this? If we ever plan to be Win32 compatible (i.e. run on a
Win32 platform.... not run one inside of the virtualization) we will need
whatever we use to do this to live INSIDE of the running code (remember,
Win32 can't do or ever _truely_ handle SysV IPC calls), although it could
very well be a library that reads and runs python scripts. These same
issues apply elsewhere.
>
> BTW, the modules I'm referring to are user space dynamically
> linked routines. What method is use to do this, is abstracted,
> another good reason to use an already implemented scripting language.
>
> With a more powerful script language, you can code arbitrary
> tests and control language. If you were to code this into
> the C code of plex86, first you are bound to having only
> the functionality you code, and also pollute the code with
> all kinds of #ifdefs.
>
>
> > Anyway, if it isn't already clear, I side with Ramon.
> Make whatever we end
> > up using simple, clear, braindead, and local (built-in). I hope that
> > somebody takes this and does something more constructive with
> it than the
> > squabbling that has thus far defined this thread.
>
> So far, this discussion has been quite useful. The biggest issue is in
> defining the needs and reasons for using a better script language.
I agree completely....... could we just spend some time to do that first,
and decide what tool to use to accomplish those goals later? As I think I
have shown earlier in this response, we don't all seem to be focusing in on
the same issues quite yet.
>
> If we don't take the time to do this, we will end up with a very limited
> piece of software, and it's going to be a bitch to debug.
>
> Also, FWIW, some of the people who have been interested in plex86 from
> the beginning have been OS design teams. I'm sure they will make use
> of every ounce of functionality we add to plex86. And I sure could
> use a ton more of it myself for testing/developing/implementing plex86.
>
> -Kevin
>
Maybe we can start now on outlining what we want to do with:
*configuation files -- defining the default state on init and/or pointing to
a live script to execute internally (possibly using something like python)
*runtime scripts & custom init scripts -- used for more in-depth & complex
tasks like those demanded by the needs of experimenters & debuggers
*a possible runtime debug prompt -- used to enter script elements into the
Plex86 "system" on the fly or to call other scripts into action.
It is my view that if we can separate out these things, define the goals of
each, and discuss possible methods of use & abuse of them--then we may be
able to better choose how to accomplish each one & if we should continue to
lump the three together as one task.
Drew Northup, N1XIM
