[Freeipmi-devel] Re: My plans

[Albert Chu]

> Though it fiid_obj_t is a typedef'd  byte array. libfreeipmi treats
> this as a special object (data-type). 

Well, my primary concern is this:

fiid_obj_t foo = fiid_obj_create(rmcp_hdr template);

ipmi_cmd_create(IPMI_GET_CHANNEL_AUTH, foo);

And kaboom, data corruption everywhere and its impossible to debug.  If 
we don't have a buffer length parameter, perhaps we need a parameter
within the fiid_obj_t that ensures that we are passing a fiid_obj_t type
of correct size.

> I think it is worth if we meet on Thursday or Friday to synchronize 
> on libfreeipmi development and strategies moving forward. If not, tell
> me, I will write a detailed email about the current design and my
> plans. It is not worth your time reading the code and grasping from
> it.

Sounds reasonable, and while I'm there, I can show you the IPMI power
control problem we're seeing here.  My ability to debug is quite limited
because I don't have access to the room their are installing/building
thunder.  My knowledge of debugging on the cisco switches is pretty
limited too.  I just locked one up ... which probably means I'll be
buying donuts for the sysadmins too :-)

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Tuesday, January 20, 2004 5:27 pm
Subject: Re: My plans

> ,----[ Albert Chu <address@hidden> ]
> | 1) Why do you hide the fiid_template_t definitions inside the .c
> |  files?  Doesn't this remove the point of having "structures" users
> |  can manipulate themselves instead of using our helper functions??
> `----
> Placing them in header files will cause multiple declaration error.
> 
> I already have some approaches over come this difficulty. Because
> this change is only cosmetic, I have delayed it until pre-release.
> 
> Right now goal is maximum functionality and correctness. We will make
> coding style corrections - between pre0 and pre2
> 
> ,----[ Albert Chu <address@hidden> ]
> | 2) Almost all the functions take a "fiid_obj_t obj_hdr" or similar
> | parameter, but no "obj_hdr_len" or similar parameter.  Is the buffer
> | length checked at any point internally in the fiid code base?  If 
> not,| I am really against having an API like this.  I talked to 
> others here,
> | and having a function that doesn't pass in a buffer length (or 
> hide a
> | buffer length internally within the abstract type) is destined for
> | bugs and problems.
> `----
> In my original code, I passed length arguments. But I changed the
> framework on purpose. Here are my explanations.
> 
> Though it fiid_obj_t is a typedef'd  byte array. libfreeipmi treats
> this as a special object (data-type). 
> 
> RULES:
> 1. All fiid_obj_t must have a template associated
> 2. User should always use fiid_obj_alloc(associated template) to
> create these objects.
> 3. fiid_obj_t is no replacement for all u_int8_t *. Means use it only
> in place of template instantiation.
> 4. fiid_* calls will fetch, all required properties like length, field
> definitions, ... from the associated template. (thats why you see no
> length argument)
> 5. Because fiid_obj_t is a special data-type, no function should
> attempt to manipulate the data directly except fiid_* APIs.
> 
> ,----[ Albert Chu <address@hidden> ]
> | 3) I am a little confused about your vision for the ipmi-lan API,
> | could you give me an example??
> `----
> Ok what I am trying to achieve is system interface neutral command
> framework. It is now possible to use, say "Get Device ID" command
> across LAN or KCS transparently.
> ...
> Ok let me commit fish utility. Thats a good working example.
> ...
> 
> I think it is worth if we meet on Thursday or Friday to synchronize 
> on libfreeipmi development and strategies moving forward. If not, tell
> me, I will write a detailed email about the current design and my
> plans. It is not worth your time reading the code and grasping from
> it.
> 
> ,----[ Albert Chu <address@hidden> ]
> | > Currently I am also merging code from freeipmi-utils package. We
> | > will be ready for a public pre0 release after that.
> | 
> | I thought the freeipmi-utils package was supposed to be a set of
> | temporary tools to help configure the BMCs for thunder.  Why 
> would we
> | need to release them??  Isn't fish supposed to be the primary
> | deliverable??
> `----
> Yes correct. I meant I am copying useful code from freeipmi-utils
> project back to libfreeipmi. :)
> We will drop freeipmi-utils soon.
> 
> --
> Albert Chu
> address@hidden
> Lawrence Livermore National Laboratory
> 
> ----- Original Message -----
> From: Anand Babu <address@hidden>
> Date: Tuesday, January 20, 2004 2:37 pm
> Subject: My plans
> 
> > You can get a snapshot of untested code at 
> > ftp://ftp.cdclinux.com/pub/ipmi/libfreeipmi-0.0.0-19Jan04.tgz
> > (for review purpose only)
> > 
> > By tomorrow hopefully I will also merge SEL support into the core.
> > and make a commit.
> > 
> > Currently I am also merging code from freeipmi-utils package. We 
> will> be ready for a public pre0 release after that.
> > 
> > Between pre0 and pre3 I will finish FreeIPMI Hackers guide.
> > 
> > Jim,
> > We will discuss IPMI Platform Event Manager strategy in a separate
> > thread.
> > 
> > -- 
> > _.|_ 
> > (_||_)
> > Free as in Freedom <www.gnu.org>
> > 
> 
> 
> 
> -- 
> _.|_ 
> (_||_)
> Free as in Freedom <www.gnu.org>
>