os_mon & alarm_handler in R10B-10

[Serge Aleynikov]

Hi Micael,

What keeps bothering me is the fact that if you examine otp_mibs 
application file, it doesn't mention the need for mnesia:

{application, otp_mibs,
  [..., {applications, [kernel, stdlib, snmp]}, ... ]}.

Consequently, release files such as the following:

{release, ...,
   [
     {kernel  , "2.10.13"},
     {stdlib  , "1.13.12"},
     {otp_mibs, "1.0.4"},
     {mnesia  , "4.2.5"},   % Mnesia is started in this case
     {snmp    , "4.7.1"}
   ]
}.

{release, ...,
   [
     {kernel  , "2.10.13"},
     {stdlib  , "1.13.12"},
     {otp_mibs, "1.0.4"},
     {snmp    , "4.7.1"}
   ]
}.

together with the application's config file containing:

   {snmp, [{agent, [..., {mibs, ["mibs/priv/OTP-MIB"]}, ...]}]}

will start by successfully loading OTP-MIB into the SNMP agent's data 
store.  Nonetheless, the later definition of the release file will lead 
to run-time errors in SNMP manager's queries to OIDs inside the OTP-MIB.

While I still think that SNMP agent shouldn't allow to load a mib if a 
'new' instrumentation function is defined for an OID, and the 'new' 
instrumentation call raises an exception, the OTP-MIB's dependency on 
mnesia should at least be documented to avoid confusion.

Regards,

Serge



Micael Karlberg wrote:
> Hi,
> 
> Yeah, I got what you where after. But what I meant was that since
> the new (and delete) function(s) are optional, exceptions is to
> be expected! And since I don't know how instrumentation functions
> are implemented, I cannot know exactly what exceptions I can
> expect (function clause, case clause, ...). This together with
> the fact that these functions have no defined reply, makes it
> simply not worth the effort to try to "handle" the reply.
> 
> Regards,
>     /BMK
> 
> Serge Aleynikov wrote:
> 
>> Micael Karlberg wrote:
>>
>>> Hi,
>>>
>>> The new (and delete) function is an optional one. Also
>>> there is no defined return value for this function.
>>> Therefor it's not worth the effort to try to figure if
>>> the result is ok or not.
>>
>>
>> BTW, I once again reread you email and realized that I should've 
>> stated  this proposal in my former email to make my point more apparent:
>>
>> _= (catch call_instrumentation(..., new)).
>>
>> change to:
>>
>> _ = call_instrumentation(..., new).
>>
>> The result still doesn't need to be examined, but I believe, the 
>> exception should not be ignored.
>>
>> Serge
>>
>>
>