On 08/26/2014 02:00 PM, Anders Bjornerstedt wrote:
> Hans Feldt wrote:
>>> -----Original Message-----
>>> From: Anders Widell [mailto:[email protected]]
>>> Sent: den 26 augusti 2014 13:13
>>> To: Zoran Milinkovic; [email protected]
>>> Cc: [email protected]
>>> Subject: Re: [devel] [PATCH 1 of 1] immtools: fix the use of
>>> extended names in immcfg [#980]
>>>
>>> Hi!
>>>
>>> Two comments:
>>>
>>> 1) I suppose this bug exists in all tools, so they other ones also need
>>> to be fixed?
>>>
>>> 2) Maybe the tools should always support long DNs, so that you don't
>>> have to set the environment variable in the shell?
>> [Hans] why would you set env vars? The tool should instead have a new
>> option
> Sure add an option also.
> But *if* you have set the environmentt variable and not set the option
> then you should get the same
> result as if you had set the option and not the environment-variable.
>
> I am assuming here you can not set the environment variable explicitly
> to not allow long DNs.
> If that where the case then the two could conflict.
Hmm, I am still thinking, but here are my current thoughts. :-) The
original intended meaning of the environment variable was to signal to
the agent that the application has been adapted to support long DNs, by
using saAisNameLend() and saAisNameBorrow() etc. We were even trying to
find a way to avoid the need for the environment variable - i.e. to find
a way for the agent to detect if the application has been compiled with
the preprocessor macro defined or not. However, this turned out to be
difficult and hence the environment variable was introduced.
So clearly with this reasoning the tools should set the environment
variable since they have been adapted. But - you could by "application"
actually mean something bigger than the tool, like the shell script
which is using the tool. Then you could potentially run into problems.
Maybe option is the way to go, as Hans suggests.
/ Anders Widell
>
> /AndersBj
>>> regards,
>>> / Anders Widell
>>>
>>> On 08/25/2014 03:44 PM, Zoran Milinkovic wrote:
>>>> osaf/tools/safimm/immcfg/imm_cfg.c | 1 +
>>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>>
>>>>
>>>> The patch enables using osaf_extended_name_* functions in the
>>>> correct way before the first saImmOmInitialize() is called.
>>>>
>>>> diff --git a/osaf/tools/safimm/immcfg/imm_cfg.c
>>>> b/osaf/tools/safimm/immcfg/imm_cfg.c
>>>> --- a/osaf/tools/safimm/immcfg/imm_cfg.c
>>>> +++ b/osaf/tools/safimm/immcfg/imm_cfg.c
>>>> @@ -1539,5 +1539,6 @@ static int imm_operation(int argc, char
>>>> }
>>>>
>>>> int main(int argc, char *argv[]) {
>>>> + osaf_extended_name_init();
>>>> return imm_operation(argc, argv);
>>>> }
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> Slashdot TV.
>>>> Video for Nerds. Stuff that matters.
>>>> http://tv.slashdot.org/
>>>> _______________________________________________
>>>> Opensaf-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
>>>>
>>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> Slashdot TV.
>>> Video for Nerds. Stuff that matters.
>>> http://tv.slashdot.org/
>>> _______________________________________________
>>> Opensaf-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
>>
>> ------------------------------------------------------------------------------
>>
>>
>> Slashdot TV. Video for Nerds. Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Opensaf-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
