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: Anand Babu
Subject: [Freeipmi-devel] Re: [llnl-devel] FreeIPMI conflict/issue list
Date: Fri, 14 Nov 2003 16:05:00 -0800
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

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]