Hank, Zdenek and others:
 
Here is a message on this topic that PPS management asked me to forward to this reflector.
---
As we've said previously, it is certainly understandable if Zdenek no longer has the bandwidth to invest in this area; we continue to thank you for your efforts thus far, Zdenek!
 
We have made a substantial investment in ipmitool over the years, with development of the patches that triggered this discussion being just a small part, but we are not prepared to take over maintenance of ipmitool for the entire community.  We'll continue to assist our customers in the relevant contexts for use of this valuable tool, but we don't have the bandwidth to have a broader involvement than that.
 
If one or more folks or companies step forward to take this responsibility, we'll be pleased to cooperate with them, as we have done to this point.  Pending that, we'll focus on supporting our own customers.
 
Thanks again, Zdenek for your contributions thus far.
 
Mark Overgaard
---
Regards,
Dmitry


29.07.2014 0:11, Zdenek Styblik пишет:
On Mon, Jul 28, 2014 at 4:15 PM, Dmitry Bazhenov <dim...@pigeonpoint.com> wrote:
[...]
It's all understood. We did our ipmitool bug-fixes on a paid basis too, so I
understand your position.
Everybody else has the same deal and it makes sense from certain
business point of view. It depends what your product is, what drives
your customers and so on. But you can say somebody from corporation A
pops up, spends some time with something, and gets pulled to other
stuff.

I'll pass the response to my employers in order to get the
plan how to
move patches further.

Please, don't get me wrong. I don't blame Pigeonpoint or you. I meant
it in general and pitching/asking for long term solution. Pretty much
all vendors should give this a thought as they're all affected one way
or another. One guy doing this in free time doesn't seem like a good
solution.
If I ever manage to un-buffer enough, I'll try to get back. It might
be next weekend, next moth or never. For better or worse, some changes
are coming in a month or so.
However, in my opinion, this project needs more than just integration
of "new features". But it's just my opinion. However, should it
continue by just integration and snowballing, then I'm no longer
needed here anymore and can move on.

[...]
On more thing, can you tell if anyone else beside you administrates
(actively) the project?
Administration like to grant commit privileges? Yes. Participating on
the project? No.
Majority of those people are/used to be from Kontron and my guess is
Kontron did whatever it needed to with IPMI tool, say an integration
of sorts, and moved on.

Have a nice evening,
Z.

Regards,
Dmitry

Best regards,
Z.

Regards,
Dmitry

16.05.2014 19:33, Zdenek Styblik пишет:

On Fri, May 16, 2014 at 2:55 PM, Dmitry Bazhenov
<dim...@pigeonpoint.com>
wrote:
Hello, all,

Can I expect any progress on the posted patches?

With regards,
Dmitry

Sure,

send over some beers ;)

Z.

--
Zdenek Styblik
email: zdenek.styb...@gmail.com
jabber: zdenek.styb...@gmail.com

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.









------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


      

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Reply via email to