Actually I did play with some prototype for it.
Now I have working console on TCP port with the following interface:
============================================================
[rokot ~] telnet localhost 41415
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
*************
Welcome to Test Agent Console.
Type "help" for command information.
*************
help
*************
Supported commands:
help
Prints this help message.
quit
Quits from the console.
ls
Shows current object.
cd <objname>
Enters to the specified object.
new <objname>
Creates new child object.
rm <objname>
Deletes the specified child object.
set <var> = <val>
Sets the specified variable in the current object.
*************
OK: Help displayed.
ls
Current object: /
Targets for cd/rm:
Targets for new:
Any Valid Entity Path
Vars:
RO enabled = TRUE
RW varSaHpiEventCategoryT = THRESHOLD | USAGE
RW varSaHpiEventStateT = STATE_00 | STATE_01 | STATE_02
RW varSaHpiSensorRangeFlagsT = MIN | MAX | NORMAL_MIN
RW varSaHpiSensorThdMaskT = LOW_MINOR
RW varSaHpiGuidT = BINARY:00000000000000000000000000000000
RW varSaHpiCtrlStateStreamTWithoutRepeat = BINARY:
RW varSaHpiCtrlStateOemTWithoutMId = BINARY:
RW varOemControlConfigData = BINARY:00000000000000000000
RW varDimiTestParamName = TEXT:xxx
RW f = 10000000000.000000
OK: Object displayed.
============================================================
My idea was to present all plug-in stuff as an object tree.
Handler is root. Resources are handler children.
Instruments are resource children. And so on.
Each object expose list of variables that can be set.
Pondering what to do next: try to attach it to existing plug-in or create
new one.
Anton Pak
On Mon, 16 May 2011 22:46:43 +0400, Lars Wetzel <[email protected]>
wrote:
> Hi Anton,
>
> you are right.
> For the FUMI case I hoped to re-use some parser classes. For this
> purpose I
> introduce a configuraton part at the top of the simulation data to be
> able to
> switch between upgrade and initialization mode. But at the moment only
> the
> latter case is implemented.
>
> Another point is to influence the simulator while runtime. I thought
> about a
> client which communicates over a socket with simulator plugin. Or do you
> think
> it makes sense to enhance the ABI interface? In such a case also other
> plugins
> can use it.
>
> Regards
> Lars
>
> On Monday, May 16, 2011 05:54:03 pm Anton Pak wrote:
>> Hello!
>>
>> I've realized that simulation plug-ins lack of runtime configuration.
>> It means we cannot change sensor reading value, insert/extract board,
>> simulate FUMI upgrade process or DIMI Test process or Watchdog outcome.
>>
>> Suggest to introduce new plug-in or to add a way of runtime
>> configuration
>> in simulator or dynamic simulator.
>>
>> What say?
>>
>> Anton Pak
>>
>> ---------------------------------------------------------------------------
>> --- Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Openhpi-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
