On 10/12/2007, Giuseppe Modugno <[EMAIL PROTECTED]> wrote:
> The fourth parameter of an handler is netsnmp_request_info type.
> This appears as a list of requests
Correct.
This is the list of varbinds from the incoming request that are
relevant to this particular handler.
> Another field is 'netsnmp_variable_list *requestvb' that is a list of variable
> bindings.
Err... no.
The four parameters to the handler routine are:
netsnmp_mib_handler *handler
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests
The original varbind list from the incoming PDU is not
passed directly to the handler routine.
> I don't understand why there are two lists:
> requests (netsnmp_request_info type)
> and requestvb (netsnmp_variable_list type).
Only the netsnmp_request_info list (of varbinds relevant
to this particular registration) is passed to the handler.
The netsnmp_variable_list contains *all* the varbinds
from the original request, and should not be touched.
Leave that to the main agent driving code.
> In the delayed_instance.c example, there isn't any cycle:
> the only variable that is processed in MODE_GET case is
> requests->requestvb and stop.
The general model is for a MIB handler to be passed all of
the relevant varbinds, so that it can process them all together.
However certain handlers work in a "serialised" mode, and
will only ever be called with one varbind.
That's true of the "instance" handler (and hence true for
the delayed_instance example too).
If you think about it, this makes sense.
The instance helper is used to implement a specific OID.
There is no need to call the user-provided handler more
than once. The instance helper handler can tell whether
the requested OID matches the registered OID or not,
and hence whether to report an error.
Even if there are two or more copies of the same OID
in the incoming varbind list, once the instance helper has
called the user-provided helper to retrieve the value, it can
then use that value for all the remaining (valid) varbinds as
well. A single call will always suffice.
> Instead, in agent/mibgroup/mibII/ip.c there is the following cycle in MODE_GET
> case:
> for (request=requests; request; request=request->next)
> but there isn't a cycle for requestvb list.
That's correct.
The IP helper is only concerned with the varbinds that are relevant
to it (the 'requests' list), not the whole of the original varbind list.
> When I register a custom scalar or a group of scalar, what should I write in
> the MODE_GET case (but also in MODE_SET and so on) in my custom handler?
Process the 'requests' list - as above.
> Are both the lists (requests and requests->requestvb) surely filled with only
> an element, or could be several elements to be processed in there?
Treat 'requests-requestvb' as a single varbind structure.
Don't try to follow the links. The only list you should be concerned
with is the 'requests->next' list.
> Should I
> implement one cycle or two nested cycles, or doesn't it matter?
Yes - it does matter.
You should implement one cycle, based on 'requests->next'
Dave
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
