On 22 Jun 2011 at 14:41, Dave Shield wrote:
> > Indeed I have other signals too: temperature, currents, RF powers and so on.
> > Do you suggest to have a different table for each signal?
>
> Yes.
>
> > For example, I have only one temperature sensor: should I create a table
> > with just one row?
>
> Yes.
>
> *At the moment* you just have one temperature sensor.
> But think what happens when you bring out a new product
> that include two temperature sensors.
> If you're using scalar objects then you'll have to bring out a
> new version of the MIB (and hope that everyone who's using
> the old one will remember to upgrade).
> If you're using a table, then everything will just continue working.
Most probably I have a bad idea on MIB files so I think with a
different point of view.
I thought a MIB file is associated to a product. For example, the
16-ports Ethernet switch SW1016 (just created name) has a MIB
associated to it SW1016-MIB.txt.
For example, it could provide the temperature of the internal CPU so
this piece of information is coded as an OID in the MIB.
Most probably the 32-ports Ethernet SW1032 of the same family could
share the same MIB of SW1016, so it could be better to have a single
MIB SW10xx-MIB.txt.
The informations about Ethernet interfaces are implemented as a
table, so the same MIB will work well for both.
Now the manufacturer designs a new wonderful 16-ports Ethernet
switch SSW1016 with two internal CPUs. I thought a new MIB SSW1016-
MIB.txt should have been created. In this case, if there are two
temperature values, they will be codede as two OIDs in the new MIB
file.
I considered the problem about sensors, but it could be a new
functionality (an integrated coffee machine in the switch).
I think it's impossible to create a MIB file that can work with
everything. And if I have to create a new MIB file for a new
product, I can simply modify it to increase/decrease the number of
sensors, the new functionality parameters and so on.
What is wrong in my words?
> > At first, it seems to me the "fixed one-row table" approach is too
> > complex compared with a single scalar/object approach.
>
> It's a bit more work (for you) in the short term, but saves work
> (for both you and your customers) in the long run.
>
>
> In fact - rather than defining your own MIB tables, I'd
> actually suggest that you look at using the existing
> sensor tables.
> Have a look at LM-SENSORS-MIB.txt
Is LM-SENSORS-MIB.txt defined in a RFC? Is it standard?
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
