[Freeipmi-devel] RMCP bug?

[Albert Chu]

That was strange, somehow an old e-mail got cut and pasted into the new
one ... lets try again.

> Hey AB,
> 
> As far as I can tell, you are never converting the RMCP IANA 
> Enterprisenumber 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??

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratories

----- Original Message -----
From: Albert Chu <address@hidden>
Date: Saturday, November 15, 2003 10:07 am
Subject: 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 
> 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 {
> 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 
> Enterprisenumber 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
> > 
> 
>