[lsb-discuss] ISP RAS framework issues/feedback/questions

Banginwar, Rajesh rajesh.banginwar at intel.com
Wed Aug 2 10:26:39 PDT 2006

>-----Original Message-----
>From: lsb-discuss-bounces at lists.freestandards.org [mailto:lsb-discuss-
>----- Original Message -----
>From: "Harring, BrianX D" <brianx.d.harring at intel.com>
>To: <lsb-discuss at lists.freestandards.org>
>Sent: Wednesday, August 02, 2006 7:53 AM
>Subject: Re: [lsb-discuss] ISP RAS framework issues/feedback/questions
>> > -----Original Message-----
>> > From: lsb-discuss-bounces at lists.freestandards.org
>> > bounces at lists.freestandards.org] On Behalf Of Denis Markovtsev
>> > Sent: Tuesday, August 01, 2006 8:15 AM
>> > To: Banginwar, Rajesh; lsb-discuss at lists.freestandards.org
>> > Subject: Re: [lsb-discuss] ISP RAS framework
>> <snip, regarding marshalling>
>> > b)  This is a very good question. Indeed, usually formal
>> specifications
>> > and
>> > methods have problems with complex data, pointers and so on.
>> Nevertheless
>> > our framework works well here. It is not necessary to transfer big
>> objects
>> > back and fourth in all cases. If an internal structure of an object
>> not
>> > interesting for us, we don't transfer it and work only with
>> to
>> > the
>> > object. But if we want to check the internal state of the object we
>> need
>> > to
>> > implement marshalling/unmarshalling. Please, note that
>> > marshalling/unmarshalling is used only along with the remote agent.
>> it
>> > is
>> > not an indispensable part of our framework because it is possible
>> write
>> > tests that do not use the agent.
>> If you're not relying on remote, how would it protect itself against
>> segfaults?  Assume the change would be shifting over to fork'ing
>> to the run?
>> ~brian
>We meant the possibility of working without remote agent.
>Distributed architecture has a number of advantages and
>our framework allows to easily implement it, that is the reason
>we use the remote agent in all our tests for the LSB Core.
>Rejection of the distributed architecture follows the loss of the
>and appearance of additional problems, especially in some specific
>of functionality under test. We only would like to note that our
>flexible enough to solve the problems both with the aid of distributed
>architecture and with the aid of other facilities available to other

As I pointed out couple of emails back, the distributed nature of this
framework will add a lot of overhead when tests are developed for
interfaces with complex set of parameters. If the user has to worry
about marshalling and demarshalling of parameters for every test of
every interface, that will add a lot of overhead while developing tests
(and potentially new bugs). 

But looks like if we get rid of the distributed nature (which to me
looks like the only option given current architecture - probably not for
LSB core or similar libraries), we will need to fix things as Brian
pointed out so that each test is run separately.



More information about the lsb-discuss mailing list