On Mon, 24 Oct 2005, Dave Shield wrote:
>
> On Mon, 2005-10-24 at 11:01 -0400, Robert Story wrote:
> > On Mon, 24 Oct 2005 14:01:44 +0100 Dave wrote:
> > DS> > I do agree with Peder on shared IPv4/IPv6 storage as a char array (and
> > DS> > that's what I did for the data access functions for the MFD
> > re-writes).
> > DS>
> > DS> As a raw character array, or some vaguely generic structure ?
> > DS> (similar to "struct sockaddr")
> >
> > Raw character array. If there is some portable structure that does ipv6 and
> > ipv4, i'd be glad to switch to it.
>
>
> Well, this isn't really my area, so I'm rather hoping Peder might chip
> in again. But not knowing what I'm talking about has never stopped me
> before, so I offer the following (hopefully portable) suggestions:
I like this remark - I don't know that much about net-snmp either - but
that doesn't stop me talking, either :-)
Unfortunately, the project where I have been using net-snmp is shutting
down, so I don't have much available time to work on net-snmp.
Nevertheless, I will "chip in". I suggest that net-snmp try to develop
its internal representation to according to a principle of matching the
MIBs, the syntaxes and the textual conventions used there, and ignore
anything else. The purpose of the exercise, after all, is not to match
specific, possibly maldesigned APIs (as the socket interface which was
originally designed for a VAX, I think, back in the '70s where people
really believed that an IP address was a VAX integer and would stay so
forever), but to make it easy for users to write extensions, preferrably
just by looking into the MIBs and the code, including the code generated
by mib2c, and not having to study coding conventions (like "remember that
this integer is really four bytes in network order").
Therefore, I suggest you develop one convention for the ASN1 type
IpAddress (which will be slowly dying out in the MIBS over the next
century but never completely). And another convention for its
replacement, the textual convention InetAddress, as described in RFC 4001.
Both, fortunately, are "u_char *"'s in "C", but there are significant
internal differences, mainly because the datatype (vars->type) is
different for the two types.
Now, we are to some extent up against the fact that "C" is a terrible
language for exactly this sort of manipulations - handling data that are
basically polymorphic. Fortunately, net-snmp has today an approach to
this which is not that bad - it just needs to be easier to work with for
IP addresses.
Therefore I suggest, that the union typedef'ed as "netsnmp_vardata" in
the include/net-snmp/library/snmp_api.h is enhanced with an extra member
typedef union {
long *integer;
u_char *ipaddress; /* <--- this is the new entry */
u_char *string;
oid *objid;
u_char *bitstring;
struct counter64 *counter64;
#ifdef OPAQUE_SPECIAL_TYPES
float *floatVal;
double *doubleVal;
/*
* t_union *unionVal;
*/
#endif /* OPAQUE_SPECIAL_TYPES */
} netsnmp_vardata;
and fix all the "switch (vars->type) { ... case ASN_IPADDRESS: ...}"
(it's a lot of places!) to operate on the ipaddress member.
As these pointers are all pointing into the "buf" member of the struct
variable_list), this change won't change one single byte access in the
entire agent (unless it is buggy already, of course), but it will make the
code much more readable, and much easier to understand by novice
programmers - and net-snmp agent is one software suite that will always be
hit by novice programmers.
There is no reason to develop new internal representations for
InetAddress; InetAddress is an OCTET STRING (SIZE (0..255)), and net-snmp
already has an internal representation for that (the "string" member of
the union).
--
At the same time, I suggest that the signatures of the functions
snmp_set_var_value and snmp_set_var_typed_value are changed so that the
polymorphic arguments that are currently "u_char *"s will in the future be
"void *"s. Again, no practical change in the running agent. But it
forces me to do sloppy programming in my extentions - I have to typecast
addresses of integer values to "char *"s to avoid warnings from the
compiler - and the implementation of the functions have to typecast them
back ....
"void *" is the acknowledged way of saying in "C": I don't know the type
of these data. "char *" sends an entirely different signal.
Hope this all helps. Keep up the great work.
best regards
--
Peder Chr. Nørgaard Senior System Developer, M. Sc.
Ericsson Denmark A/S, Telebit Division
Skanderborgvej 232 tel: +45 30 91 84 31
DK-8260 Viby J, Denmark fax: +45 89 38 51 01
e-mail: [EMAIL PROTECTED]
(old e-mail 2000-2003: [EMAIL PROTECTED])
(old e-mail 1992-2000: [EMAIL PROTECTED])
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
