Re: [Qemu-devel] [PATCH 00/17] Update to adding an IPMI device to qemu

[Corey Minyard <minyard@acm.org>]

On 04/26/2015 06:39 AM, Andreas Färber wrote:
> Am 24.04.2015 um 01:11 schrieb Eric Blake:
>> On 04/23/2015 04:57 PM, minyard@acm.org wrote:
>>> The major changes from last time are:
>> That says this series should probably be named v2 (git
>> format-patch/send-email -v2) or later, as part of the subject line. If
>> the previous version is more than a couple weeks ago, it's also nice
>> (but not required) to provide a URL to the archives of the previous
>> discussion.
> Even worse, I don't see any update on the licensing questions previously
> raised... did Intel ever get back to you?

This is the last update I received from Bret Ketchum.  From what he says
we will get nothing from Intel on this and everything seems ok:

  From my understanding you'll not be receiving anything official from
Intel. My understanding from Tom is that there are open source KCS/BT
drivers existing in the wild with no IPMI adopters asserting IP on those
drivers. The specification places requirement son VMC but does not do
the same for software.

    The Adotpers Agreement may be looked at as benign/beneficial. At one
level the agreement limits the extent that fellow Adopters can assert IP
claims against other signers.

    I only bring this up (again) in that I've a request for the update
to these patches I mentioned on the mailing list.

    Another option may be for some other than yourself to post these
patches which would absolve you from any recompense.


On Thu, Mar 6, 2014 at 6:48 PM, Corey Minyard <minyard@acm.org
<mailto:minyard@acm.org>> wrote:

    On 03/06/2014 06:02 AM, Bret Ketchum wrote:
    >
    >
    >     What needs to be done to unstick the IPMI patches? Are you waiting
    > on something from Intel legal? My email exchanges with Tom Slaight and
    > Akkiah_Maddukuri do not suggest a legal issue with regards to a shim
    > protocol that facilitates a IPMI client talking to an IPMI server.
    >

    I'm waiting for something from Intel.  I don't have contact info for
    anyone at Intel.  And email from Tom Slaight would probably be good
    enough

    It's more than just a shim protocol, too.  There is an implementation of
    simulated KCS and BT hardware and a small simulated BMC that provides
    basic function and a watchdog.  We could lose the BMC, but not the
    hardware simulations.

    Thanks,

    -corey

    >
    > On Tue, Mar 4, 2014 at 6:38 PM, <minyard@acm.org
    <mailto:minyard@acm.org>
    > <mailto:minyard@acm.org <mailto:minyard@acm.org>>> wrote:
    >
    >     This patch set was part of the IPMI patches, but people have asked
    >     it to be
    >     separated out because it's useful by itself and the IPMI patches
    >     are stuck
    >     in legal limbo.
    >
    >     I have left the patch to move allocating CharDriverState in
    one place
    >     (patch 1).  I didn't get much opinion either way, but I think
    it is
    >     an improvement and a net reduction in code.  I also added a patch
    >     (patch 6)
    >     that goes another step there, it makes the error handling in
    >     qmp_chardev_add() consistent and is also a net reduction in code.
    >
    >     The main patches to add the feature are patch 2 and patch 3.
    >
    >     The rest are little possible bug fixes that I noticed while
    >     working in the
    >     code.
    >
    >     I went through all the comments and I believe I fixed everything.
    >
    >     Thanks to everyone that reviewed this before.
    >
    >