[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Freeipmi-devel] Re: My plans
From: |
Albert Chu |
Subject: |
[Freeipmi-devel] Re: My plans |
Date: |
Tue, 20 Jan 2004 19:00:51 -0800 |
> 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>
>