RE: [libsmi] Regarding Unsigned64 interpretation by SMILINT
We import it using CISCO-TC MIB .
Thanks Rohit
-----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Thursday, May 04, 2006 1:08 PM To: Rohit Palthad Venkataramana (rovenkat) Cc: libsmi@ibr.cs.tu-bs.de Subject: Re: [libsmi] Regarding Unsigned64 interpretation by SMILINT
On Thu, May 04, 2006 at 01:02:31PM +0530, Rohit Palthad Venkataramana (rovenkat) wrote:
Sorry for the later response , I was out of the office .
The below is the definition of Unsigned64 object
ciscoTestRate64 OBJECT-TYPE SYNTAX Unsigned64 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "The committed policing rate. This is the sustained rate permitted by policing."
::= { ciscoTestRate 11 }The mib is in my controll .I even checked for other mibs also ,smilint
gives same error for Unsigned64 object .
So how is Unsigned64 defined / imported? The SMIv2 itself does not have an Unsigned64 data type, only SPPI has it.
/js
On Thu, May 04, 2006 at 01:39:04PM +0530, Rohit Palthad Venkataramana (rovenkat) wrote:
We import it using CISCO-TC MIB .
OK. So you essentially have a definition for Unsigned64 which should be valid as long as it is used by SMIv2 modules but it should be invalid if used by SPPI modules and libsmi always complains. I am not sure how easy it will be to fix this because libsmi treats Unsigned64 internally as a base type and Counter64 actually as a type derived from Unsigned64 (basically following the SMIng model). Frank, do you have an idea how to address this name clash?
For now, I have written a test case for libsmi and checked it into the SVN repository which demonstrates the problem.
/js
Juergen Schoenwaelder wrote:
On Thu, May 04, 2006 at 01:39:04PM +0530, Rohit Palthad Venkataramana (rovenkat) wrote:
We import it using CISCO-TC MIB .
OK. So you essentially have a definition for Unsigned64 which should be valid as long as it is used by SMIv2 modules but it should be invalid if used by SPPI modules and libsmi always complains. I am not sure how easy it will be to fix this because libsmi treats Unsigned64 internally as a base type and Counter64 actually as a type derived from Unsigned64 (basically following the SMIng model). Frank, do you have an idea how to address this name clash?
For now, I have written a test case for libsmi and checked it into the SVN repository which demonstrates the problem.
I have just modified the parser so that it now accepts (and warns) about such type definitions that match existing SPPI or SMI base type names.
$ SMIPATH=:test/mibs ./tools/smilint test/mibs/LIBSMI-TEST-018-MIB test/mibs/LIBSMI-TEST-018-MIB:41: warning: definition of identifier `Unsigned64' which is already a SMI or SPPI basetype
participants (3)
-
Frank Strauß -
Juergen Schoenwaelder -
Rohit Palthad Venkataramana (rovenkat)