2007/12/10, Dave Shield <[EMAIL PROTECTED]>:
> 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.

OK, now it is clear.
If two variables in a GET PDU are related to a single handler, that
handler is called only one time with a 'requests' list of two elements
(fourth parameter of the handler).
I thought that the handler was called two times, one time per variable.


> > 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.

So requests->requestvb is originally a list, but it is processed by
the agent and not by the module.


> > 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.

Ok, I'll do it.


> > 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.

Ok.


> 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).

Scalar helper is based on instance handler, so it is serialized too.
Is it correct?


> > 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.

But that is true for group of scalars only. I think a single variable
registered as a scalar could be treated as an instance, so requests
has surely only *one* element and I needn't to process the 'requests'
list. Is it correct?


> >                                             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'

Again, for a single scalar variable it doesn't matter... does it?
It does matter only for group of scalars (and for other different handlers).

-------------------------------------------------------------------------
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

Reply via email to