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.
---
Regards,
Dmitry 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, DmitryBest 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, DmitrySure, send over some beers ;) Z. -- Zdenek Styblik email: zdenek.styb...@gmail.com jabber: zdenek.styb...@gmail.com17.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