freeipmi-devel
[Top][All Lists]
Advanced

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

[Freeipmi-devel] RE: [llnl-devel] Marshall/Unmarshalling talk


From: Rice, Bryan
Subject: [Freeipmi-devel] RE: [llnl-devel] Marshall/Unmarshalling talk
Date: Tue, 9 Dec 2003 09:02:53 -0800

In response to:
"Perhaps Bryan could enlighten us with Intel's goals on IPMI.  Are you
guys going to push this hard onto all vendors??  Does Intel want
everyone to adopt this??  I haven't the slightest idea ..."

I myself am not an IPMI expert.  I followed up with our TME who supports IPMI, 
and he responded with:
" Our goal is to create standards-based server management.  Intel has been 
pushing IPMI adoption for 5 years now.  We have ~160 adopters and growing.  
Yes, we'd love to have everyone adopt it."

If this response is not adequate, perhaps I can set you up with this IPMI TME 
for a phone call.

Let me know,
Bryan E. Rice
Technical Marketing Engineer
Application Design-In Center
 

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Albert Chu
Sent: Wednesday, December 03, 2003 9:22 AM
To: Anand Babu
Cc: llnl-devel; address@hidden
Subject: [llnl-devel] Marshall/Unmarshalling talk

> Nobody likes the "byte array" model. Code is utterly unreadable. 
> But when portability is #1 goal, there is no choice.

It is only unreadable after you marshall it.  The idea is:

ipmi_pkt_create(&pkt);
printf("foo = %d\n", pkt.foo);
// Do whatever your heart desires with pkt
length = marshall_pkt(&pkt, buffer, buflen);
sendto(fd, buffer, length);

The packet is still 100% readable/editable until just the moment
it is sent on the network.

> I will support "struct / #pragma pack" approach, until someone
> convinces me with clear examples when and where this model will break,
> how often we will hit them.

Right now, FreeIPMI will be 100% guaranteed to break if:

A) A compiler does not support #pragma pack(1)
   - But this is probably rare and only on older machines which
     don't support IPMI.

   - In addition, if your compiler doesn't support byte alignment
     in structures.  i.e.

     struct foobar {
         u_int8_t foo:4; 
         u_int8_t bar:4;
     };

     The odds are the compiler won't support pragma pack anyway.

   - So, to some extent, I am willing to accept pragma pack(1)
     alignment.  But I will let Ben talk.  He's going to have 
     thouoghts on this.

B) A processor is big-endian
   - Is it reasonable to assume IBM or Apple (maye Sun, I can't 
     remember) will never use IPMI??
   - Itaniums can be Big or Little Endian.  Is it reasonable to
     assume users will always have itaniums in little endian mode??
     People do wierd things ... 

C) A compiler aligns data in their structures differently
   - There is no guarantee that any compiler will align the data
     exactly like we want it.  
   - There is no guarantee GCC will continue to align the data
     exactly like we want it.
      
Obviously, what we choose to do depends on the goals of FreeIPMI.  We
(LLNL) would personally like to see it become a library that everyone
out there loves and uses.  Non-portability means some developers may
decide not to go with it.  

Perhaps Bryan could enlighten us with Intel's goals on IPMI.  Are you
guys going to push this hard onto all vendors??  Does Intel want
everyone to adopt this??  I haven't the slightest idea ...

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory



_______________________________________________
llnl-devel mailing list
address@hidden
http://californiadigital.com/cgi-bin/mailman/listinfo/llnl-devel




reply via email to

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