Re: [llnl-devel] Re: [Freeipmi-devel] kcs byte array model - validation

[Albert Chu]

Hey AB,

> I have one more idea in my mind. IDL approach. Tell me if what you
> think.

Do you mean something like:

IDL ipmi_get_session_challenge { 
   {"auth_type", 64th bit, 4 bytes long},
   {"privilege_max", 68th bit, 4 bytes long}
}

Then in some marshall code:

marshall_get_session_challenge(struct get_session_challenge *cmd) {
   int bits_written = 0;
   foreach key-offset-length KOL in ipmi_get_session_challenge
       MARSHALL(buffer, bits_written, cmd, KOL);
}

And the MARSHALL macro would do macro magic to convert "cmd" and
"auth_type" into "cmd->auth_type", copy into the buffer, increment
bits_written, etc. etc. etc.

I like this idea.  I think it'd save us a lot of time.  But there
are some fears I have.

1) I am only visuallizing a crude macro-hackish way, but if we use some
macro hacks, are those macro hacks portable??  I'm sure there are
cleaner ways that I just can't see in my head right now ... 

2) How do we handle packet types with optional return fields??  For
example, the get chassis status command response will return either 4 or
5 bytes of data.  The fifth byte can optionally be implemented by the
manufacturer.  The unmarshall chassis status response would unmarshall
based on the length of the packet returned.  Can this be added into the
IDL easily??

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

> ,----[ Albert Chu <address@hidden> ]
> | I like this.  I think in my last e-mail, I was getting "unassemble"
> | confused with "ipmi_recvfrom".  We have already read the buffer from
> | the socket.  So it is in the hands of the user to unassemble the
> | packet however they wish.
> `----
> Yes absolutely.
> 
> ,----[ Albert Chu <address@hidden> ]
> | We can probably add some dinky macros that let the user get the
> | "pkt_id" based on a fixed position.
> `----
> You always did a good job in beautifying my code :)
> 
> ,----[ Albert Chu <address@hidden> ]
> | But for the most part, this is done.  And since
> | marshalling/unmarshalling is hidden within assemble/unassemble, we
> | don't have to debate malloc() vs. no malloc().  We'll just use 
> static| buffers.
> `----
> Just curious to know how safe is malloc inside library. Portability,
> Multi-threading, any other ...
> 
> ,----[ Albert Chu <address@hidden> ]
> | Time to list and divide up work???
> `----
> As usual, I will fix the whole framework and check-in to CVS. 
> Hopefully savannah will be up in 2 days. Otherwise we will setup local
> CVS or use tar-ball/patch approach temporarily.
> 
> There are few things you can do outside the frame-work till then.
> Like Ian did SMBIOS probe.
> 
> I have one more idea in my mind. IDL approach. Tell me if what you
> think.
> 
> We can define the packet structures using a simple interface
> description language and write generic C functions to use them as
> templates for ipmi-cmd-values <=> byte array conversion.
> 
> IDL can be something like
> 
> template name
>  key, address, offset (bit level), default-value (optional)
>  key, address, offset (bit level), default-value (optional)
> 
> First thing to evaluate is,
> - What and how much we save by using this approach
> - Advantages
> - Disadvantages
> 
> -- 
> Anand Babu
> CaliforniaDigital.com
> Office# +1-510-687-7045
> Cell# +1-510-396-0717
> Home# +1-510-894-0586
> 
> Free as in Freedom <www.gnu.org>
>