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

[Anand Babu]

,----[ 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>