Hello, all,
Can I expect any progress on the posted patches?
With regards,
Dmitry
17.04.2014 17:55, Dmitry Bazhenov пишет:
Hello, ipmitool maintainers,
I would like to submit several patches which adds some new
functionality into ipmitool, as well as fix some bugs.
1. [bugs:#305]
deferred-activation-fix.diff
This patch fixes the ipmitool HPM.1 agent which
mis-recognizes the deferred activation support and reports
invalid deferred firmware image version.
2. [bugs:#306]
fru-info-fix.diff
This patch removes duplicate output of FRU info #0 when
command fru print all is sent.
3. [bugs:#307]
i82751spt-fix.diff
This patch adds missing check in the LAN+ implementation for
Intel i82751 MAC which has known deviations from the IPMI v2.0
specification.
4. [patches:#94]
vita-support.diff
This patch adds VITA 46.11 specification support to
ipmitool.
5. [patches:#95]
intf-reopen-fix.diff
This patch provides a solution how to overcome the
architectural ipmitool drawback which
makes impossible to normally (without hacks) close and
re-open interface.
Please, review.
Regards,
Dmitry
31.03.2014 22:28, Dmitry Bazhenov пишет:
Zdenek,
Here is the updated patch.
Regards,
Dmitry
31.03.2014 13:37, Dmitry Bazhenov пишет:
Zdenek,
Okay then. I'll provide the updated patch later today.
Regards,
Dmitry
31.03.2014 13:34, Zdenek Styblik пишет:
On Mon, Mar 31, 2014 at 9:14 AM,
Dmitry Bazhenov <dim...@pigeonpoint.com>
wrote:
Hello, Zdenek,
I think there should be no such checks inside these
callbacks.
However, I guess there should be a check inside thr
ipmi_intf_set_max_request/response_data_size
functions which guarantee that the minimum value will be
not less than 25
bytes (required by IPMI spec).
Could you please add such check or is it better for me to
provide a new
patch revision?
Regards,
Dmitry
Dmitry,
I don't have access to any IPMI capable hardware, so I'm
afraid it's
either up to you or somebody else. I'm sorry.
Best regards,
Z.
31.03.2014 13:07, Zdenek Styblik
пишет:
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.
|
