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

[Albert Chu]

Hmmm.  Actually, would a set of wrapper around

ssize_t ipmi_kcs_read (u_int16_t sms_io_base, u_int8_t *bytes, u_int32_t
bytes_len);
ssize_t ipmi_kcs_write (u_int16_t sms_io_base, u_int8_t *bytes,
u_int32_t bytes_len);

be better? I like the idea of having a set of routines that are
fiid_obj_t independent, so users can pass in buffers developed by their
own libraries.

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: Albert Chu <address@hidden>
Date: Tuesday, November 9, 2004 2:49 pm
Subject: Re: RE: RE: [Freeipmi-devel] New utilities using FreeIPMI

> 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 
> theirown 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
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 
> _______________________________________________
> Freeipmi-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/freeipmi-devel
>