freeipmi-devel
[Top][All Lists]
Advanced

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

[Freeipmi-devel] Re: [llnl-devel] FreeIPMI conflict/issue list


From: Albert Chu
Subject: [Freeipmi-devel] Re: [llnl-devel] FreeIPMI conflict/issue list
Date: Sat, 15 Nov 2003 09:43:26 -0800

> Albert Chu <address@hidden> writes:
> I think we should remove ipmi_errno and rename the file to
> ipmi_error.c
> 
> You tell me what you are going to fix. I wont touch that part of the
> code. :)

Sounds good ...  I'll start adding the packet dump functions into a new
ipmi_error.c file at some point.
 
> We should take packing effect seriously and fix them, before the code
> evolves further.
> 
> I'm not having a clear picture of how you are going to implement
> marshalling. Can you throw me an example code.

Ben Woodard has far more experience in this area than me, b/c he worked
on porting/fixing lpd for a number of years.  But he suggests something
along the lines of:

marshall_ipmi_pkt(ipmi_pkt *pkt, char *buf, int buflen) {
   memcpy(&buf[0], pkt->char_val, 1);
   memcpy(&buf[1], to_little_endian(pkt->int_val), 4);
   memcpy(&buf[5], pkt->netfn << 2 | pkt->lun, 1);
}

Unmarshalling would be the opposite, putting values into the appropriate
fields.  Its painful and mind numbing to code, but several developers
agree that it must be done to avoid problems down the road.

I found yet another reason to do the marshalling and unmarshalling.

struct foo {
   int a: 2;
   int b: 6;
};

On some compilers/machines/whatever foo's will be aligned "a:b" in
memory, while others align it "b:a" ... 

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratories

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Friday, November 14, 2003 4:05 pm
Subject: Re: [llnl-devel] FreeIPMI conflict/issue list

> Albert Chu <address@hidden> writes:
> >I didn't even notice the ipmi_errno variable.  Is this even 
> necessary? 
> >I would think this is only necessary if we wrote much higher level
> >functions, such as "ipmi_setup_session" or something.  In the current
> >framework errors will exist in packet completion codes or in
> >sendto/recvfrom.  I feel its ok for errors from sendto/recvfrom to be
> >passed back to the user via libc errno.  I still don't know your 
> code as
> >well as you, so you perhaps see something I don't see.
> 
> I think we should remove ipmi_errno and rename the file to
> ipmi_error.c
> 
> You tell me what you are going to fix. I wont touch that part of the
> code. :)
> 
> >Although its painful, and a lot of code, ultimately I think this 
> is the
> >safest approach.  The compiler aligns the structures in the memory 
> just>like we want them to, but there is no guarantee they'll do 
> that in the
> >future.  
> >
> >An added bonus is that marshall/unmarshall functions will allow us to
> >fix endian issues.  We have a lot of IBM laptops floating around.  If
> >any of the sysadmins want to use ipmipower on those laptops, 
> libfreeipmi>will completly bomb right now.
> 
> We should take packing effect seriously and fix them, before the code
> evolves further.
> 
> I'm not having a clear picture of how you are going to implement
> marshalling. Can you throw me an example code.
> 
> 
> Happy Hacking
> -- 
> Anand Babu
> CaliforniaDigital.com
> Office# +1-510-687-7045
> Cell# +1-510-396-0717
> Home# +1-510-894-0586
> 
> Free as in Freedom <www.gnu.org>
> 





reply via email to

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