On Thu, Mar 20, 2014 at 6:54 AM, Zdenek Styblik <zdenek.styb...@gmail.com> wrote: > On Wed, Mar 19, 2014 at 8:33 AM, Dmitry Bazhenov <dim...@pigeonpoint.com> > wrote: > [...] >>> I got a bit "scared" by solution applied to >>> ipmi_intf_get_max_request_data_size() and >>> ipmi_intf_get_max_response_data_size(). But then I've tried to compile >>> just this one function with all kinds of switches and compiler didn't >>> comply, so I guess it's ok. >>> I wonder, shouldn't be the same logic applied to >>> ipmi_lanp_set_max_rq_data_size() and ipmi_lanp_set_max_rp_data_size() >>> as well? >> >> [DB] Calculations in the ipmi_intf_get_max_request_data_size() are required >> for the case if the target IPMC device is accessed via IPMI bridging. Since >> we can not deduce the target channel maximum message size, we use the >> minimum required size. These calculations are not needed for direct IPMC >> device access. >> [DB] Set max size functions are required if maximum message size over the >> chosen interface must be somehow modified from the value received from the >> interface properties. This is the case for the encrypted RMCP+ payload where >> maximum message size must be reduced by the confidentiality header/trailer >> sizes. Other interface types do not even implement these callbacks. >> > > What I meant is whether under/over-flow shouldn't be checked in those > functions as well. >
Ping? Z. ------------------------------------------------------------------------------ _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
