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

[Albert Chu]

Hey Andrew,

I take it with this approach we would need some type of
fiid_obj_malloc(int len) kind of function??  Because the user uses their
own library, then needs to copy their buffer into a fiid_obj_t buffer??

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: "Cress, Andrew R" <address@hidden>
Date: Tuesday, November 9, 2004 8:23 am
Subject: RE: RE: [Freeipmi-devel] New utilities using FreeIPMI

> Al,
> 
> Right.  
> wrt a set of functions, it would only need to be one new subroutine 
> perinterface, 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 
> coulduse 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
> > > 
> > 
> > 
> 
>