Menu
▾
▴
Re: [Ipmitool-devel] [BMR #81324] PigeonPoint Systems various patches
|
From: Dmitry B. <di...@pi...> - 2014-05-16 13:22:26
|
<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, all,<br>
<br>
Can I expect any progress on the posted patches?<br>
<pre class="moz-signature" cols="72">With regards,
Dmitry</pre>
17.04.2014 17:55, Dmitry Bazhenov пишет:<br>
</div>
<blockquote cite="mid:534...@pi..." type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true"
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 moz-do-not-send="true" 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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>
|
