Re: [Ipmitool-devel] [BMR #81324] PigeonPoint Systems various patches

[Hank B. <ha...@jb...>]

Mark Ov,
is PPS going to answered this ?
hank bruning
Jblade


On Mon, Jul 28, 2014 at 10:15 AM, Dmitry Bazhenov <di...@pi...>
wrote:

> Hello, Zdenek,
>
> Please, see below.
>
> 28.07.2014 15:00, Zdenek Styblik пишет:
> > On Fri, Jul 25, 2014 at 7:39 AM, Dmitry Bazhenov <di...@pi...>
> wrote:
> >> Hello, Zdenek,
> > Hello Dmitry,
> >
> >> Could you or someone else from the development team comment
> >> on the acceptance of the following bugfix/feature patches:
> >>
> > if I had time to do so, I'd have done it already. And I have no ETA
> > when I'll have time to get back to IPMI tool again, at least not now.
> Understood.
> >
> > [...]
> >> There have been no comments on them for two months already.
> > There have been no activity what so ever for two months already. It
> > would be worth to ask why and perhaps start looking for some solution,
> > wouldn't it? It's not just patches from Pigeonpoint, but bug reports
> > and patches from other users as well.
> > I simply don't have any free time left to do this stuff at the moment.
> > And forgive me for putting a "hobby" on the back-burner. Perhaps even
> > further than that.
> > I've also noticed the past couple months a demand for almost an
> > enterprise level of response times on code review and integration has
> > appeared. I fully understand reasoning behind it and I believe it's
> > even good for project itself. I mean, that's great, because it means
> > somebody is using it and cares about it(there were couple bug reports
> > from other users as well - great!). However, let me put one thing
> > straight. It's not going to happen on my side, for free, in my free
> > time - *EVER*. I'm not 20 years old student anymore. Sorry.
> > I'm open to talk about kickstarter, sponsoring, even being
> > hired(although under very, very specific conditions); in order to cut
> > on other activities(= job[s]) and shift focus to IPMI tool. This
> > project would use at least one full time and vendor independent
> > programmer.
> > Now, I have a better idea. How about you guys drop this
> > I-can't-talk-to-other-guys-because-they're-competitors malarkey and
> > start cooperating? And I truly mean cooperating. Also,
> > improving/cleaning up/fixing the code itself, not just integrating
> > more and more bloat on top of it. How about to convince your managers
> > and their managers and so on about this? Linux kernel is being/getting
> > done this way, doesn't it? Also, Linus and Greg K.H. are being paid by
> > Linux Foundation, so neutrality, or independent mediators, is secured.
> > Hopefully, you know what I mean.
> > Because I simply can't see other way for this project. Either way,
> > somebody has to pay (for dev time). Nothing comes for free.
> > Kontron used to have paid developers dedicated to this project, but I
> > guess their focus have shifted.
> It's all understood. We did our ipmitool bug-fixes on a paid basis too,
> so I understand
> your position. I'll pass the response to my employers in order to get
> the plan how to
> move patches further.
> >
> >> Will appreciate any feedback.
> > One feedback, though. Fix code formatting, if nothing else. I'm not
> > going to do it for you, or anybody else, anymore. It got tiresome
> > after 1+ year of doing so; I can do better things than that; and I
> > don't have that much of free time to do so(see previous reason).
> >
> > Sorry for bad news, but reality check was necessary from my point of
> view.
> Nevermind. Thanks for the support anyway, we appreciate it.
>
> On more thing, can you tell if anyone else beside you administrates
> (actively) the project?
>
> 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 <
> di...@pi...>
> >>> wrote:
> >>>> Hello, all,
> >>>>
> >>>> Can I expect any progress on the posted patches?
> >>>>
> >>>> With regards,
> >>>> Dmitry
> >>>>
> >>> Sure,
> >>>
> >>> send over some beers ;)
> >>>
> >>> Z.
> >>>
> >>> --
> >>> Zdenek Styblik
> >>> email: zde...@gm...
> >>> jabber: zde...@gm...
> >>>
> >>>> 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 <
> di...@pi...>
> >>>> 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
> >>>> <zde...@gm...> wrote:
> >>>>
> >>>> On Wed, Mar 19, 2014 at 8:33 AM, Dmitry Bazhenov <
> di...@pi...>
> >>>> 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
> >>>> Ipm...@li...
> >>>> 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
> Ipm...@li...
> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>