Hi,
The purpose of the ticket is to make TCP as default transport.
The 00-README.conf is updated about the changes that the user has to do
to use TIPC.
It also contains description of the new variables in nid.conf
who values have to be backed-up by upgrade scripts.
-AVM
On 10/8/2013 5:56 PM,
-Original Message-
From: Anders Widell [mailto:anders.wid...@ericsson.com]
Sent: Monday, October 07, 2013 5:58 PM
To: Mathivanan Naickan Palanivelu; Hans Feldt
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] opensaf: change daemon_exit to call exit() [#581]
I
Ok, I can see that it's included at end of saImmOm.h
Thanks'
Lennart
-Original Message-
From: Anders Björnerstedt
Sent: den 8 oktober 2013 16:46
To: Lennart Lund; mathi.naic...@oracle.com; Hans Feldt
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1 of 1] logsv: Add
This is good but it seems you could use a helper function (like I proposed for
AMF). Now there is a lot of duplication.
Something like:
void imm_admin_op_result(handle, inv, status, const char *format, ...)
/Hans
-Original Message-
From: Lennart Lund
Sent: den 8 oktober 2013 16:41
What I am talking about is configuration migration that should done by the rpm
scriptlets. I thought we were responsible for the rpm specs as long as they are
included in opensaf?
Besides the osaf-transport-monitor seems to consume a lot of CPU load. There is
something wrong with it. Please
Hi Lennart,
- I'm suggesting to phrase the text that introduces the table (section 3.5.3.1)
to as below:
The SAI-AIS-LOG-A.02.1 spec is ambiguous in its definition of the tokens @Cd,
@Nd.
The OpenSAF LOG service implementation defines the behavior for these format
tokens as below:
- In the
Ack from me.
I guess we should also go through the code and make sure we follow this
rule from the Google C++ Style guide:
Static and Global Variables
Static or global variables of class type are forbidden: they cause
hard-to-find bugs due to indeterminate order of construction and
Wasn't it IMM that got into trouble last time we played with exit() :-)
These objects will be destroyed when we call exit(). Are they accessed
by any thread besides the main thread?
Anyway, I suppose it wouldn't be too hard to change these variables into
pointers, and initialize them the first
And no they are not acccessed by any other thread than the main thread.
The problem we had, if I remember correctly, was an exit() had been inserted in
the
signal handler. This pulled the rug out from under the main thread of course.
But that problem was quickly fixed once we realized what it
