On Tue, 23 Nov 2004 14:01:34 +0000 Dave wrote: DS> > The idea was that the user module shouldn't have to worry about DS> > creating/deleting rows. DS> DS> It's perfectly reasonable that the user module shouldn't *have* to worry DS> about creating rows. I'm less happy that they're effectively not allowed DS> to do so! If you think back over some of my arguments with Wes, I'm DS> usually arguing in favour of increased flexibility - the default setup DS> should be as convenient as possible, but the toolkit shouldn't obstruct DS> the MIB implementer if they want to work in a slightly different way.
And I think that I usually argue the same way. And you'll notice that the MFD code does not handle creating/deleting rows. And a good bit of the internals is right there in xxxTable_interfaces.c, if you are bold enough to venture in there. (Eventually I hope to move most of it into a helper, to reduce bloat.) DS> > The set mode callbacks are *always* called with a valid row DS> > context, even if it is a new one that isn't in the container yet. DS> > I'll argue that [this] outweighs the performance hit of an extra DS> > allocate/delete for invalid set attempt. DS> DS> You're probably right. But I'd prefer to see the MIB implementer DS> being offered that choice. It wouldn't be too hard to add a flag which could be set during registration, and would signal the helper to not create the row. I'd have to look at the code to see what that might break... DS> > If createAndWait is specified and a column without a default value DS> > is not specified in the varbind, the row will be notReady until all DS> > rows have a value specified.... Once all columns have values, the row DS> > transitions to notInService. DS> DS> That feels basically right, if a little simplistic. DS> I can envisage situations where a table might well be missing two DS> or three "minor" column values, but still be ready to go live. I think that the RowStatus TC doesn't allow that. Step 3 of row creations says, for columns with non-defaulted values: - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column [...]. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. DS> Distinguishing between 'notInService' and 'notReady' feels better DS> left to the 'can_activate' hook, rather than hardwired into the helper. I don't think the wording of the RowStatus TC allows that... In particular, the current code can transition from notInService to notReady, which I also think is not allowed. It's a shame, because it would be nice to get an indication, in advance, that the agent thinks a row is ready to go active. But the TC explicitly states that "'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device". I thought it did, which is why the code works the way it does. DS> > The easy fix is to immediately transition to notInService instead DS> > of notReady. DS> DS> That would be my suggestion, yes. DS> The code in the 'get_value' routine for the RowStatus object should DS> probably call the 'can_activate' routine explicitly, to dynamically DS> check whether the row was ready or not. DS> After all, it's possible that this might also depend on some external DS> subsystem - not just the internal column values. If it worked the way I thought it did, that would be a good idea. But it looks like can_activate should only be called when the row is actually being set to active. DS> That would also handle an active row becoming 'notReady' (due to some DS> external change), and then back to active again. I can probably come DS> up with a plausible scenario if you need one :-) Hmm.. I think it would have to be notInService instead of notReady. The TC doesn't have any restrictions on the agent automatically moving between active and notInService, so I guess anything goes! DS> > I've just submitted a bug report for that, but don't expect to get DS> > around to fixing it real soon... DS> DS> Oh, none of this is very urgent. DS> I'm just trying to feed back various comments as they occur to me. DS> I wouldn't suggest you put a lot of work into this just yet. No worries. I just wanted to get it somewhere besides my mail archives, where it's likely to get forgotten.. -- Robert Story; NET-SNMP Junkie Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp> Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
