[Freeipmi-devel] Re: My plans

[Anand Babu]

,----[ Albert Chu <address@hidden> ]
| > 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.
`----
Did you see the second email I sent you. It describes having data len
inside the obj in future. 

Right now this is how it works.

obj_foo = fiid_obj_alloc (tmpl_foo);

and you call 
ipmi_cmd_foo (obj_foo)
{
 u_int64_t obj_len = fiid_obj_len_bytes (tmpl_foo);
 ...
}

We actually do a boundary check based on the obj length always.

,----[ Albert Chu <address@hidden> ]
| > 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 :-)
`----
May be you can ask Jim to help us with Cisco switch conf without
donuts ;-)

Let us debug while you are here. First we need to reproduce the
problem here are CDC!.

Did you test with cross-over cable?

Did you check the ARP table?

-ab

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



-- 
 _.|_ (_||_) Free as in Freedom <www.gnu.org>