[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freeipmi-devel] Re: My plans

From: Anand Babu
Subject: [Freeipmi-devel] Re: My plans
Date: Tue, 20 Jan 2004 17:27:53 -0800
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

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

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

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

Free as in Freedom <>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]