Menu
▾
▴
[Ipmitool-devel] [BMR #81324] PigeonPoint Systems various patches
|
From: Dmitry B. <di...@pi...> - 2014-04-17 12:22:25
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hello, ipmitool maintainers,<br>
<br>
I would like to submit several patches which adds some new
functionality into ipmitool, as well as fix some bugs.<br>
<br>
1. <strong><a class="alink"
href="http://sourceforge.net/p/ipmitool/bugs/305/">[bugs:#305]</a>
</strong>deferred-activation-fix.diff<br>
This patch fixes the ipmitool HPM.1 agent which mis-recognizes
the deferred activation support and reports invalid deferred
firmware image version.<br>
<br>
2. <strong><a class="alink"
href="http://sourceforge.net/p/ipmitool/bugs/306/">[bugs:#306]</a></strong>
fru-info-fix.diff<br>
This patch removes duplicate output of FRU info #0 when
command fru print all is sent.<br>
3. <strong><a class="alink"
href="http://sourceforge.net/p/ipmitool/bugs/307/">[bugs:#307]</a></strong>
i82751spt-fix.diff<br>
This patch adds missing check in the LAN+ implementation for
Intel i82751 MAC which has known deviations from the IPMI v2.0
specification.<br>
<br>
4. <strong><a class="alink"
href="http://sourceforge.net/p/ipmitool/patches/94/">[patches:#94]</a></strong>
vita-support.diff<br>
This patch adds VITA 46.11 specification support to ipmitool.<br>
<br>
5. <strong><a class="alink"
href="http://sourceforge.net/p/ipmitool/patches/95/">[patches:#95]</a></strong>
intf-reopen-fix.diff<br>
This patch provides a solution how to overcome the
architectural ipmitool drawback which<br>
makes impossible to normally (without hacks) close and re-open
interface.<br>
<br>
Please, review.<br>
<strong></strong>
<pre class="moz-signature" cols="72">Regards,
Dmitry</pre>
31.03.2014 22:28, Dmitry Bazhenov пишет:<br>
</div>
<blockquote cite="mid:533...@pi..." type="cite">Zdenek,
<br>
<br>
Here is the updated patch.
<br>
<br>
Regards,
<br>
Dmitry
<br>
<br>
31.03.2014 13:37, Dmitry Bazhenov пишет:
<br>
<blockquote type="cite">Zdenek,
<br>
<br>
Okay then. I'll provide the updated patch later today.
<br>
<br>
Regards,
<br>
Dmitry
<br>
<br>
31.03.2014 13:34, Zdenek Styblik пишет:
<br>
<blockquote type="cite">On Mon, Mar 31, 2014 at 9:14 AM, Dmitry
Bazhenov <a class="moz-txt-link-rfc2396E" href="mailto:di...@pi..."><di...@pi...></a> wrote:
<br>
<blockquote type="cite">Hello, Zdenek,
<br>
<br>
I think there should be no such checks inside these
callbacks.
<br>
However, I guess there should be a check inside thr
<br>
ipmi_intf_set_max_request/response_data_size
<br>
functions which guarantee that the minimum value will be not
less than 25
<br>
bytes (required by IPMI spec).
<br>
<br>
Could you please add such check or is it better for me to
provide a new
<br>
patch revision?
<br>
<br>
Regards,
<br>
Dmitry
<br>
<br>
</blockquote>
Dmitry,
<br>
<br>
I don't have access to any IPMI capable hardware, so I'm
afraid it's
<br>
either up to you or somebody else. I'm sorry.
<br>
<br>
Best regards,
<br>
Z.
<br>
<br>
<blockquote type="cite">31.03.2014 13:07, Zdenek Styblik
пишет:
<br>
<br>
<blockquote type="cite">On Thu, Mar 20, 2014 at 6:54 AM,
Zdenek Styblik
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:zde...@gm..."><zde...@gm...></a> wrote:
<br>
<blockquote type="cite">On Wed, Mar 19, 2014 at 8:33 AM,
Dmitry Bazhenov <a class="moz-txt-link-rfc2396E" href="mailto:di...@pi..."><di...@pi...></a>
<br>
wrote:
<br>
[...]
<br>
<blockquote type="cite">
<blockquote type="cite">I got a bit "scared" by
solution applied to
<br>
ipmi_intf_get_max_request_data_size() and
<br>
ipmi_intf_get_max_response_data_size(). But then
I've tried to compile
<br>
just this one function with all kinds of switches
and compiler didn't
<br>
comply, so I guess it's ok.
<br>
I wonder, shouldn't be the same logic applied to
<br>
ipmi_lanp_set_max_rq_data_size() and
ipmi_lanp_set_max_rp_data_size()
<br>
as well?
<br>
</blockquote>
[DB] Calculations in the
ipmi_intf_get_max_request_data_size() are
<br>
required
<br>
for the case if the target IPMC device is accessed via
IPMI bridging.
<br>
Since
<br>
we can not deduce the target channel maximum message
size, we use the
<br>
minimum required size. These calculations are not
needed for direct IPMC
<br>
device access.
<br>
[DB] Set max size functions are required if maximum
message size over
<br>
the
<br>
chosen interface must be somehow modified from the
value received from
<br>
the
<br>
interface properties. This is the case for the
encrypted RMCP+ payload
<br>
where
<br>
maximum message size must be reduced by the
confidentiality
<br>
header/trailer
<br>
sizes. Other interface types do not even implement
these callbacks.
<br>
<br>
</blockquote>
What I meant is whether under/over-flow shouldn't be
checked in those
<br>
functions as well.
<br>
<br>
</blockquote>
Ping?
<br>
<br>
Z.
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
|
