[Freeipmi-devel] Re: [llnl-devel] New FreeIPMI API thouoghts

[Albert Chu]

> I tried this approach and dropped it. 
> We will have to maintain at least 8 structures and 3 functions for
> every command. This will soon become a nightmare. Remember we have not
> thought about bt or serial (basic, PPP) interfaces yet.

Good point.  However, I still find it unacceptable that that request
packets are created such that session or request header data cannot
be accessed in a clean manner.  Perhaps the interface should be made
something like:

assemble_pkt(rmcp_hdr_t *rmcp_hdr, ipmi_session_t *ipmi_session,
             ipmi_request_hdr_t *ipmi_rq, void *ipmi_cmd, int 
             ipmi_cmd_len, void *buffer, int buflen);

To some extent mirror the unassemble functions.

> That was just to reduce the number of arguments. But it makes sense to
> split them. You want to do this?

I'm making some changes right now, I can do it ...
 
> Look at the 3rd argument. As a convention, all input arguments are
> placed first.

Oh, that's right, you like doing it that way :-)

> I removed rmcp_hdr from rmcp_ping structure to make it consistent with
> the IPMI command structures. 
 
Then perhaps we need a "ping_assemble" function of some sort.  Requiring
the user to do as you have in your ipmi-wrappper.c:

  struct {
    rmcp_hdr_t rmcp_hdr;
    rmcp_asf_presence_ping_t asf_presence_ping;
  } lan_pkt;

  rmcp_asf_hdr (&lan_pkt.rmcp_hdr);
  rmcp_asf_presence_ping (msg_tag, &lan_pkt.asf_presence_ping);
  ipmi_lan_sendto(fd, &lan_pkt, sizeof(lan_pkt));

I think is too much ... especially making the lan_pkt structure.

Al


Hmmm, its 9:35, so I don't think I'm coming ...

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory