[Sorry for the delays in responding. Things have been
a little hectic recently - both at work and domestically]
On 28/06/07, Robert Story <[EMAIL PROTECTED]> wrote:
> On Sun, 17 Jun 2007 15:11:26 +0100 Dave wrote:
> DS> I'm just thinking that if we're looking to separate out the data_access
> code,
> DS> it would be appropriate to try and ensure that these routines are as
> DS> "MIB-agnostic" as possible - that the coding used for a given data_access
> DS> module shouldn't restrict the choice of MIB coding style.
>
> So, by 'MIB-agnostic', I'm assuming you just mean nothing specific to a
> particular handler... e.g. embedded netsnmp_containers or next/prev pointers.
Sort-of, yes.
What I'm really thinking is that a MIB module implementation (or any
other code), should be able to use one of these data abstraction modules
to supply the necessary subsystem information - without this restricting
the style of code used to implement the MIB module.
And ideally, without even needing to know much about how this 'data'
module was written.
I suspect that what this means is providing a suitable set of API calls
for each data module - perhaps something along the lines of the
'table_generic' framework. So it would be possible to insert, delete or
retrieve entries from the data module, without directly relying on its
internal implementation. (And hence it should also be possible to
change that internal implementation without affecting any of the
MIB modules or other code that uses it).
Now in many cases, these API calls would probably be trivial wrappers
round the internal implementation mechanisms. Maybe even inline
expansions or macros. But I'm keen to keep that level of separation
between data and MIB code.
> What about a member for the actual MIB index? Especially for cases where the
> index is in no way related to any existing data for the item (eg hrDeviceId /
> hrDiskStorageTable).
I'd expect each data module to provide one (or more) means of indexing
into the contents - based on the characteristics of that particular subsystem.
A given MIB module could then choose whether to use that index directly,
or apply some form of mapping into the MIB index value(s).
Such a mapping would basically be the responsibility of the MIB code,
rather than the data abstraction layer. After all, there could easily be two
or three MIB modules that made use of the same underlying system, but
with different indexing requirements (e.g. hrDiskStorageTable,
hrStorageTable, UCD dskTable, etc)
How those secondary indexes are stored is a separate matter.
The clean approach would be to hold them within the relevant MIB module,
rather than as part of the data module itself. That would imply a suitable
API for handling such mappings.
It might prove convenient to store these secondary indexes within the
main data structure, but I'd still like to see appropriate (trivial) API calls,
to localise the scope of this decision.
> The other thing I'd really like to do is standardize on how the data
> collection
> is accessed. As you might expect, I'm partial to netsnmp_containers.
I'm certainly sympathetic to using containers, and this would probably be
the default choice for most data modules. But I think it would be a mistake
to insist on this, or for MIB code to rely directly this being the mechanism
used. Hence the suggestions above about providing API calls for each data
module, and using those in the MIB code, rather than working directly
with the container API calls.
That would mean something like
myMIB.c:
myRow *row = myRow_get_row_by_index( myTable, 27 );
where
myData.c:
inline myRow *myRow_get_row_by_index( void *table, int i ) {
return (myRow *)CONTAINER_GET((netsnmp_container *)table), i);
}
rather than
myMIB.c:
myRow *row = (myRow*)CONTAINER_GET( myTable, 27 );
(The syntax probably isn't quite right, but you get the idea)
Dave
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
