Libsmi March 2009

libsmi@ibr.cs.tu-bs.de

3 participants
3 discussions

Re: [libsmi] libsmi 0.4.8 XML mapping problem with fixed OctetString Default Values
by Jens Engel 30 Mar '09

30 Mar '09

On 30.03.2009, at 13:00, Juergen Schoenwaelder wrote: > On Mon, Mar 30, 2009 at 10:34:17AM +0200, Jens Engel wrote: >> >> On 30.03.2009, at 10:20, Juergen Schoenwaelder wrote: >> >>> On Sat, Mar 28, 2009 at 04:43:55PM +0100, Jens Engel wrote: >>>> RELEASE: libsmi 0.4.8 >>>> >>>> XML mapping of default value for fixed-sized binary OctetStrings is >>>> wrong now (or at least sometimes). >>>> NOTE: Was correct in libsmi 0.4.7. >>>> >>>> DLSW-MIB::dlswTConnConfigSapList: >>>> DLSW-MIB::dlswIfSapList: >>>> DEFVAL { 'aa000000000000000000000000000000'H } >>>> becomes 'ff000...'H in XML format: >>>> <default>0xff000000000000000000000000000000</default> >>>> >>>> IPSEC-SPD-MIB::spdTimeFiltDayOfMonthMask: >>>> DEFVAL { 'fffffffffffffffe'H } >>>> becomes in XML format: >>>> <default>0xffffffffffffffff</default> >>>> >>>> >>>> >>> I can't reproduce this problem using libsmi rev=13631 on a 32-bit >>> Linux system. The code compiles and produces the right output. Can >>> you >>> check again and/or provide some more details? >>> >>> /js >> >> I will try, but I have currently no easy access to Linux system. >> I discovered it on MACOSX 10.5.6. I can try it with Cygwin, too. >> It will probably take 1 day or 2. > > Revision 13631 seems to work for me on MacOS X 10.4.11 and 10.5.6. > > /js Works for me, too (FIXED on the HEAD). I also reproduced the 0.4.8 problem under Cygwin on a PC. Therefore, I assume that problem was fixed (again) sometime after the last release. ADDITIONAL REMARKS: 1. By the way, I had some problems to compile the current HEAD on my MAC. The problem appears with "parser-yang.y" when using GNU bison 1.4.1. When I used the MAC native bison 1.3, everything was fine. Therefore, I assume there might be a problem with this grammar part when using a newer bison version during the next release. 2. In addition, 3-4 tests of the testsuite are failing on MACOSX (3 for 0.4.7/0.4.8 and 4 for the HEAD). Under Cygwin, only 1 test failed for version 0.4.8. I will look into this issue probably next week. (I already looked at some diff files. It looks like only the line numbers are slightly off?!?) 3. MINOR ISSUE: On the current HEAD, "make distclean" does not cleanup all temporary files. I did not check older versions. shell> svn status ? depcomp ? missing ? install-sh ? test/dumps/yang/Makefile.in ! win/config.h ? lib/parser-yang.c ? lib/parser-yang.tab.h ? lib/scanner-yang.c M lib/parser-smi.c Ciao, Jens Engel

1 0

libsmi 0.4.8 XML mapping problem with fixed OctetString Default Values
by Jens Engel 30 Mar '09

30 Mar '09

RELEASE: libsmi 0.4.8 XML mapping of default value for fixed-sized binary OctetStrings is wrong now (or at least sometimes). NOTE: Was correct in libsmi 0.4.7. DLSW-MIB::dlswTConnConfigSapList: DLSW-MIB::dlswIfSapList: DEFVAL { 'aa000000000000000000000000000000'H } becomes 'ff000...'H in XML format: <default>0xff000000000000000000000000000000</default> IPSEC-SPD-MIB::spdTimeFiltDayOfMonthMask: DEFVAL { 'fffffffffffffffe'H } becomes in XML format: <default>0xffffffffffffffff</default> I just discovered that when I compared the XML mapping of libsmi with a number of SNMP-MIBs (My "project" should contain most public MIBs that are also distributed wtih libsmi). NOTE: Other mappings may also be affected. I tried to checkout and use the current Subversion HEAD (rev=13629). But it is currently in an unusable state, probably due to the announced changes (a few days ago). Ciao, Jens Engel

2 1

libsmi function naming conventions
by Juergen Schoenwaelder 16 Mar '09

16 Mar '09

Hi, we are implementing support for an additional data modeling language and it seems that the feature set of the language we are currently working on is pretty different from the classic SMI/SPPI/SMIng languages libsmi supports. So the question was raised to what extend it makes sense to try to retrofit things into existing data structures and APIs or whether we should have a separate set of data structures and API functions. We believe, the later approach makes more sense and API usage simpler. It will also make it clearer at the API level that you have to call explicit conversion functions if you want to convert a module between different languages. So in a nutshell, functions with the smi prefix or data types with the Smi prefix would be SMI/SPPI/SMIng specific while functions with some other prefix would be specific to other data modeling languages. Now, there are a bunch of API functions that are really not specific to the SMI/SPPI/SMIng languages but to the library as a whole. I am talking about the functions documented in the smi_config(3) manual page essentially. If the follow the path that the API function prefixes indicate the "framework" they should be used with, then these library infrastructure functions should actually have a "libsmi" prefix, so you would write libsmiInit() or libsmiSetSeverity() or libsmiSetErrorHandler(). Providing ABI backward compatibility should be easy; I think this is more a question how we envision the evolution of this library. Comments? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/>

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Libsmi March 2009