RE: RE: [Freeipmi-devel] New utilities using FreeIPMI

[Cress, Andrew R]

Al,

Right.  
wrt a set of functions, it would only need to be one new subroutine per
interface, i.e.: ipmi_kcs_cmd_raw & ipmi_lan_cmd_raw.

Andy

-----Original Message-----
From: Albert Chu [mailto:address@hidden 
Sent: Friday, November 05, 2004 8:07 PM
To: Cress, Andrew R
Cc: address@hidden
Subject: Re: RE: [Freeipmi-devel] New utilities using FreeIPMI


Hey Andrew,

I guess what you're suggesting is a set of functions, where a user could
use their own code rather than FreeIPMI's library to build packets?? 
And FreeIPMI would act as just the driver??

Makes sense.  

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: "Cress, Andrew R" <address@hidden>
Date: Tuesday, November 2, 2004 1:44 pm
Subject: RE: [Freeipmi-devel] New utilities using FreeIPMI

> Al,
> 
> Currently, I'm doing an _open function, that does either
> ipmi_kcs_io_init() or, for ipmi_lan, the socket functions and
> ipmi_open_session().  No problem.
> 
> What I was thinking of is something alongside the ipmi_lan_cmd() and
> ipmi_kcs_cmd_interruptible() functions, that did not use templates,
> like:
> 
> int8_t 
> ipmi_kcs_cmd_raw (u_int16_t sms_io_base, u_int8_t lun, u_int8_t fn, 
> fiid_obj_t obj_cmd_rq, int cmd_rq_len, 
> fiid_obj_t obj_cmd_rs, int *cmd_rs_len);
> 
> int8_t 
> ipmi_lan_cmd_raw (u_int32_t sockfd, struct sockaddr *hostaddr, 
> size_t hostaddr_len, u_int8_t auth_type, u_int32_t session_seq_num, 
> u_int32_t session_id, u_int8_t *auth_code_data, u_int32_t
> auth_code_data_len, 
> u_int8_t net_fn, u_int8_t lun, u_int8_t rq_seq,     /* same so far 
> */ 
> fiid_obj_t obj_cmd_rq, int cmd_rq_len, 
> fiid_obj_t obj_cmd_rs, int *cmd_rs_len);
> 
> Where cmd_rs_len would be an INPUT/OUTPUT param, specifying the 
> receivebuffer size on input and reporting the actual received size 
> on output
> (like recvfrom does).
> 
> I guess the app could build something like that from already exposed
> functions in the API like ipmi_*sendto/ipmi_*recvfrom, but there is
> still value in packaging the send/recv logic in a _cmd_ function, I
> think.  And moreso if it comes with the library.  
> 
> Andy
> 
> -----Original Message-----
> From: Albert Chu [mailto:address@hidden 
> Sent: Tuesday, November 02, 2004 4:24 PM
> To: Cress, Andrew R
> Cc: address@hidden
> Subject: Re: [Freeipmi-devel] New utilities using FreeIPMI
> 
> 
> Hi Andrew,
> 
> > 1) It would be nice to have a "passthrough" type support in the
> > libfreeipmi for IPMI commands that are formed by another 
> > application
> 
> Do you mean a generic API like:
> 
> ipmi_bmc_write(char *buf, int len);
> ipmi_bmc_read(char *buf, int len);
> 
> And the user would be responsible for calling ipmi_kcs_io_init() 
> beforehand?  I guess I'm having trouble visualizing what you're 
> suggesting.
> Al
> 
> --
> Albert Chu
> address@hidden
> Lawrence Livermore National Laboratory
> 
> ----- Original Message -----
> From: "Cress, Andrew R" <address@hidden>
> Date: Tuesday, November 2, 2004 8:10 am
> Subject: [Freeipmi-devel] New utilities using FreeIPMI
> 
> > Folks,
> > 
> > Thanks for your help in resolving my issues.  
> > 
> > I have now released the version of the IPMI Management Utilities 
> that> supports FreeIPMI at http://ipmiutil.sf.net, and FreeIPMI 
> does broaden
> > the capability of these tools, so that they can still be used if 
> an 
> > IPMIdriver is not present.
> > 
> > I have two suggestions for a TODO list:
> > 
> > 1) It would be nice to have a "passthrough" type support in the
> > libfreeipmi for IPMI commands that are formed by another 
> > application, so
> > that it would just use the data bytes and data length instead of
> > templates.  I've worked around this by dynamically building a 
> template> (that won't otherwise be used), but it does add some 
> memory and CPU 
> > timeto do so.
> > 
> > 2) It would be nice to add SMBus support to libfreeipmi (NSC 
> chipsets> use this).  This lends itself nicely to user-space 
> libraries, since
> > lm-sensors is set up that way already.  There is some existing code
> > implementing IPMI over SMBus at http://sf.net/projects/openipmi. The
> > OpenIPMI driver v33 has an smb module, which uses lm-sensors via a
> > kernel thread.  
> > 
> > Andy
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Freeipmi-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/freeipmi-devel
> > 
> 
>