Hi Anton see my answer below.
Regards Lars On Monday, May 16, 2011 10:04:46 pm Anton Pak wrote: > Lars, > > My concerns: > > 1) It would be very good if Win32 plug-in version is available. > For dynamic_simulator and simulator this will require substantial changes. > Oh, I didn't know it that there is a dependency to the win32 plugin. Ok, this is a killer argument. > 2) Simulator plug-in doesn't seem as a good target. Currently it shows only > small set of hard-coded resources and instruments. Required changes are > also substantial. > Right and it isn't supported anymore. > 3) Making simulator plug-in dynamically configurable may raise a question: > why not dynamic simulator. :) > No problem - with the exception of 1.) > 4) And I don't know about simulator plug-in users. > May be they will be disappointed because of functional changes. > The dyn. simulator has at minimum the same functionality as the old simulator. (One reason for the existing simulator.data example file - it's the data from the old simulator). As the name tells us: dynamic - so why not introducing an enhancement for the simulator? > 5) The same as 4) but for dynamic_simulator. > see above > 6) If the target if dynamic_simulator: With console we would have two > ways to model system: 1) simulation data file, 2) console. > And the syntax is different. > The question would be which of them is primary. > The simulation data is only read during startup. Afterwards you can influence it only by HPI functions. Therefore there is at the moment no way to e.g. insert a new resource or to change sensor data. >From my point of view the syntaxt must be different for such an enhancement, because it must stated out that this is no HPI-B functionality which is not covered by any specification. My idea was to open a socket in the background and to influence the data in the simulator by another hpi client. Similiar to your solution and to the ipmi plugin where the system information comes also over another socket. > 7) And if the target if dynamic_simulator there are still big code changes > required. Do you think so? Ok: The win32 issue. But beside this issue a wrapper class should be enough to convert the data between both formats? Don't forget - the dyn. simulator is object oriented. Look inside the code. It's really simple and the methods are described. > > I'll be happy if you'll dispel my concerns! > Due to the win32 problem, I don't know if I could. But maybe I could give you the one or other idea ... > Anton Pak > > On Mon, 16 May 2011 23:41:59 +0400, Lars Wetzel <[email protected]> > > wrote: > > Hi Anton > > > > Writting another plugin means that all HPI functions for the clients > > must be > > provided again and an interface for a bulk set of data is needed. > > > > Enhancing the existing plugin means to wrap the plugin data structure to > > your > > objects. > > > > From my point of view it would be easier to enhance the existing plugin > > since > > you will have anything as objects and need only the enhance the one or > > other > > list. > > Furthermore the interface for loading data and for the HPI functions > > already > > exists. In case of any issue / enhancement only one plugin has to be > > maintain. > > My humble opinion is: Be free and enhance the plugin. > > > > Ciao > > > > Lars > > > > On Monday, May 16, 2011 08:58:03 pm Anton Pak wrote: > >> 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 > > --------------------------------------------------------------------------- > --- 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 ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Openhpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openhpi-devel
