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

Alexey V. Khoroshilov khoroshilov at ispras.ru
Wed Aug 2 09:32:53 PDT 2006

----- 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 [mailto:lsb-discuss-
> > 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 issues/feedback/questions
> <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 is
> not
> > interesting for us, we don't transfer it and work only with pointers
> 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. So
> it
> > is
> > not an indispensable part of our framework because it is possible to
> 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 prior
> 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 advantages
and appearance of additional problems, especially in some specific kinds
of functionality under test. We only would like to note that our framework
flexible enough to solve the problems both with the aid of distributed
architecture and with the aid of other facilities available to other


More information about the lsb-discuss mailing list