Re: [Tsp-devel] [RFC] Generating a BB from MIBS

[Frederik Deweerdt]

On Thu, Mar 01, 2007 at 11:23:00PM +0100, Eric Noulard wrote:
> 2007/2/27, Frederik Deweerdt <address@hidden>:
> >The proposed modus operandi is the following:
> >Step 1: The lib is executed, it registers a blackboard and a SNMP agent
> 
> I'm not sure to understand that step.
> What lib? The one generated by the script who parsed xml to produce C?
Exactly, we've got SNMP MIB -libsmi-> xml -ruby script-> C -> libmib.so
libmib.so can be used in two ways:
A) A stand alone program that creates a BB mapping the MIB and a SNMP
  Agent (it has its own main())
B) A lib linked to a user program that creates the BB mapping and a SNMP
  Agent (through lib calls)

Here's a more detailed explanation:

A) scenario: libmib.so used as a standalone program, user1 and user2
being linked to libmib.so

SNMP Agent <-1- libmib.so -1-> BB <-2- user1
                                \---2- user2

B) scenario: user1, user2 and user3 linked to libmib.so

SNMP Agent <-1- user1  -1-> BB <-2- user2
                             \---2- user3

1) Master mode: creates/publishes
2) Slave mode: attaches/subscribes


So process is as follows in B):
- we launch user1
        - try to create blackboard
                - succeed -> master mode -> publish, agent X
 
- we launch user2 (or user3)
        - try to create blackboard
                - failed -> slave mode -> attach, subscribe, no agent

The user2 can send an message to user1, requesting to be informed on
changes on OID XYZ. User1 registers it and will be informing user2 when
the automatically generated setters are used or the SNMP modify a variable
in the BB.

One important thing is that, generated code set aside, user2 or user1
behave exactly the same, it is just the way the memory is allocated
(subscribe or publish) that changes.

> >Step 2: The programs willing to use those variables attach themselves
> >to the blackboard, subscribe to the variables and use the BB's message
> >API to register (and later receive) SNMP events.
> >
> >We plan to provide an API to access to the black board variables
> >through setters and getters. There will be 4 versions of it:
> >- Simple setter/getter directly accesses the shared memory
> >- Locked setter/getter locks the BB before setting/getting the shared memory
> >- Event generating setter: sends an message to the programs that
> >registered a listener on a particular variable
> >- Locked event generating setter, see above :)
> 
> Don't know SNMP lib very well but does the API you want to add
> to BB just mimic the SNMP lib API?
> 
> As we already discussed BB core should remain simple and small API,
> ideally this kind of API should be built around "genuine BB core".
I think so, the generated C is just a bunch of structures and bb_publish
calls publishing them.
On top of that, there are getters and setters that allow registering for
events through the existing BB msg queues.
IOW, there's no new code planned for the BB (besides the varname stuff
:)). I plan to use the messaging API to be able to register for events
happening in the BB, use the sem primitives for locking etc.
> 
> >
> >The script is written in Ruby (the anguage for fast, easy programming
> >;) ) and generates C. It's still under developpement. Any thoughts?
> 
> Yes I would be very interested in being able to offer SNMP access
> to application which already use a BB.
> 
> Would it be possible (?and how difficult?) to write
> some kind of bb_dump_snmp which may dump a MIB
> out of a already built BB?
> 
> The idea is the following:
> 
> 0) You have a program that is already using BB lib
> 
> 1) You dump
>    bb_dump mybb -f SNMP_MIB -o mybb.mib
> 
> 2) Run your  ?generic? snmp agent which is able
>     to attach itself to the BB
> 
> May be we even don't need 1) and your agent is already able
> to attach itself to the BB and offer SNMP access?
I think that I see what you mean, and I had something similar in mind:
Nowadays the process is:
MIB -> xml -> data structure -> generated C code (structs + bb calls
+SNMP)
I think it could be possible to have something like
C header files -> data structure -> generated C code (bb calls + SNMP)
while reusing most of the code.
By data structure I mean the following: I have a Node class with methods
such as

.get_c_type
.get_c_decl
.get_bb_publish
.get_snmp_register

which generate the appropriate C structs/calls/whatever
The first version of the script is tightly coupled to a proprietary XML
format. The first step I want to take before releasing it is to work
with the standard libsmi's format for representing MIBs. I believe that
if the parsing interface is generic enough, it could parse a BB or header
files or anything.

Fred