Re: Magic number and the #define

[Dave S. <D.T...@cs...>]

> I ran the mib2c to generate C codes. The tool defines the table entries
> for two tables all together. The number of the second table entries
> continues from the last entry of the first table. So the actual #define
> for table entry of table one begins from 1 to 20 and for table entry of
> table two begins from 21 to 25 for my case.  

So all of the magic numbers are unique.
Good.

> According to the comment in the example.c  "The magic number defined in
> the example header file. This is passed to the callback routine and is#
> used to determine which object is being queried."

Which it can do, since the magic numbers are unique.

>  And the comment in the example.h "Magic number definitions. These must
> be unique for each object implemented within a single mib module callback
> routine.

Which they are.


> Typically, these will be the last OID sub-component for each entry,
> or integers incrementing from 1. ..."

But that doesn't really matter, as long as they are unique, which they
are.   So things look fine.

> From the above description I have doubt I may have to separate the
> #define for two table entries.

Why?

> Each table begins from 1. Therefore in the routine of var_XYZTable() the
> switch() statement will map the name and the vp->magic correctly.
> Otherwise the vp->magic 21 to 25 will never be matched to the query
> entry because the actual queried oid  is from 1 to 5.

The magic number is matched against the defined constants.
It's not matched against the OID subidentifiers.

These *might* be the same (hence the comment in example.h) but it's
not necessary (hence the continuation of the same comment).

It's the *last* field of the variableN structure that is used to
construct the OID of relevant object.   The first field is a purely
arbitrary magic number.  As long as it is unique (within a given
variable handling routine) then things should work.

Have a look at the FAQ entry
   How can I support a large table, with more than 256 column objects?
for an illustration of how your assumptions are wrong.


> Am I correct? 

No.

>         	If my suspicion is correct.
> What is the best approach to correct it?

It doesn't need correcting.

> The design style in ucd-snmp breaks in parts for disk, proc, file, ..
> tables and do the initialization of each table in their corresponding C file.

Yes.
Because we're typically supporting a range of different approaches (on
various different architectures) for a single table.  So it's useful to
implement the various groups separately, despite them being part of the
same (fairly large) MIB file.   Otherwise the file would end up even more
convoluted than it currently is!

> Can I do the REGISTER_MIB for two tables in the init_xxx() routine so
> I don't need to break the C codes into two files?

Yes, of course.
You can even register two tables in the same init_xxx() routine, but
implement one of them in a separate file.
See 'mibII/ip.c' which includes a registration of the "iproute" group,
but the code that actually implements this table is in "mibII/var_route.c"


> What is the pitfall I may not know if I REGISTER_MIB for two tables
> in one routine?

None that I can think of.
It's probably worth implementing them as separate var_xxx routines,
unless the two tables are *very* closely linked.
But if one table AUGMENTs the other (for example), then it makes sense
to use a single var_xxx routine as well  (see "host/hr_swrun.c")


Dave