Dmitry, The release of 1.8.15 is not going to come about anytime soon given that no one has had the time to code review or commit these or any other bugfix/feature patches recently. Z has been the most active ipmitool developer for quite some time, and I have been trying to help out when I can. There really isn't anyone else helping out with ipmitool at this point in time. I'm the person who has been responsible for cutting the release as well as doing part time development and code reviews when I get a chance. I've got the time to continue in this role, and I'll see if I can free up some more time to get some of the defect fixes into ipmitool end of Aug or early Sept.
Jim On 7/24/2014 11:39 PM, Dmitry Bazhenov wrote: > Hello, Zdenek, > > Could you or someone else from the development team comment > on the acceptance of the following bugfix/feature patches: > > #307 Intel I82751 super pass through mode fixup > #319 Interface safe re-open. > #320 VITA 46.11 support > #328 HPM.2 fixes > #329 hpm.1 upgrade fixes > > There have been no comments on them for two months already. > We would want them incorporated into the mainline sources before the > 1.8.15 release if possible. > > Will appreciate any feedback. > > 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 >>> > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > > -- > --- Jim Mankovich | jm...@hp.com (US Mountain Time) --- ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
