[Freeipmi-devel] Re: My plans

[Albert Chu]

> Did you see the second email I sent you. It describes having data len
> inside the obj in future. 

Yeah, that was along the idea I had.

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

Well here's what we're doing on thunder:

In 1 window:

thunderi> su root
thunderi> conman ethunderXXX

In another window:

thunderi> su root
thunderi> pdsh -w ethunderXXX /sbin/halt

- Wait until system is finished halting in conman window

- Try any ipmi or rmcp commands messages to see if ethunderXXX is
reachable.  

thunderi> ipmipower -h ethunderXXX -u foo -p bar --stat
thunderi> rmcpping ethunderXXX
           ^^ I don't know if this is installed on address@hidden

> Did you test with cross-over cable?

Haven't been able to yet, b/c I don't have access to the room with
Thunder in it ... :'(

> Did you check the ARP table?

thunderi still showed the mac address in the arp table (/sbin/arp -a),
so I gather this means the BMC is still sending out gratuitous arps ...

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

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

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