[Freeipmi-devel] Sounds good ... I'll start adding the packet dump functions into a new

[Albert Chu]

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 {
RMCP bug??
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hey AB,

As far as I can tell, you are never converting the RMCP IANA Enterprise
number from little endian to big endian, and RMCP packets are required
to be in big endian form (12.3.1)...  Is it working??  Perhaps Intel
made their chips handle both??

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratories

----- Original Message -----
From: Albert Chu <address@hidden>
Date: Saturday, November 15, 2003 9:43 am
Subject: [Freeipmi-devel] Re: [llnl-devel] FreeIPMI conflict/issue list

> > 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 
> newipmi_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 
> workedon porting/fixing lpd for a number of years.  But he suggests 
> somethingalong 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 
> appropriatefields.  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>
> > 
> 
> 
> 
> _______________________________________________
> Freeipmi-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/freeipmi-devel
>