From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jobin Raju George Subject: Re: Why I advise against using ivshmem Date: Fri, 13 Jun 2014 14:59:33 +0530 Message-ID: References: <20140610184818.2e490419@nbschild1> <53978375.6090707@6wind.com> <87ppie1v4r.fsf@blackfin.pond.sub.org> <20140612094413.15e56938@nbschild1> <87vbs6qjhj.fsf_-_@blackfin.pond.sub.org> <5399CF09.8030803@6wind.com> <87ppidnqmy.fsf@blackfin.pond.sub.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b2e3d92b30bbb04fbb4501e Cc: Henning Schild , kvm@vger.kernel.org, QEMU Developers , David Marchand , sagar patni , virtualization@lists.linux-foundation.org, Vincent JARDIN To: Markus Armbruster Return-path: In-Reply-To: <87ppidnqmy.fsf@blackfin.pond.sub.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org --047d7b2e3d92b30bbb04fbb4501e Content-Type: text/plain; charset=UTF-8 Nahanni's poor current development coupled with virtIO's promising expansion was what encouraged us to explore virtIO-serial [1] for inter-virtual machine communication. Though virtIO-serial as it is isn't helpful for inter-VM communication, some work is needed for this purpose and this is exactly what we (I and two of my fellow classmates) accomplished. We haven't published it yet since we do need to polish yet for upstreaming it and are planning do it in near future. [1]: http://fedoraproject.org/wiki/Features/VirtioSerial On Fri, Jun 13, 2014 at 2:16 PM, Markus Armbruster wrote: > Some dropped quoted text restored. > > Vincent JARDIN writes: > > > Markus, > > > > see inline (I am not on all mailing list, please, keep the cc list). > > > >> Sure! The reasons for my dislike range from practical to > >> philosophical. > >> > >> My practical concerns include: > >> > >> 1. ivshmem code needs work, but has no maintainer > > See David's contributions: > > http://patchwork.ozlabs.org/patch/358750/ > > We're grateful for David's patch for qemu-char.c, but this isn't ivshmem > maintenance, yet. > > >> - Error handling is generally poor. For instance, "device_add > >> ivshmem" kills your guest instantly. > >> > >> - More subjectively, I don't trust the code to be robust against > >> abuse by our own guest, or the other guests sharing the memory. > >> Convincing me would take a code audit. > >> > >> - MAINTAINERS doesn't cover ivshmem.c. > >> > >> - The last non-trivial commit that isn't obviously part of some > >> tree-wide infrastructure or cleanup work is from September 2012 > >> (commit c08ba66). > >> > >> 2. There is no libvirt support > > > > One can use qemu without libvivrt. > > You asked me for my reasons for disliking ivshmem. This is one. > > Sure, I can drink my water through a straw while standing on one foot, > but that doesn't mean I have to like it. And me not liking it doesn't > mean the next guy shouldn't like it. To each their own. > > >> 3. Out-of-tree server program required for full functionality > >> > >> Interrupts require a "shared memory server" running in the host (see > >> docs/specs/ivshmem_device_spec.txt). It doesn't tell where to find > >> one. The initial commit 6cbf4c8 points to > >> . That repository's last commit is from > >> September 2012. He's dead, Jim. > >> > >> ivshmem_device_spec.txt is silent on what the server is supposed to > >> do. > > > > We have the source code, it provides the documentation to write our > > own better server program. > > Good for you. Not good enough for the QEMU community. > > QEMU features requiring on out-of-tree software to be useful are fine, > as long as said out-of-tree software is readily available to QEMU > developers and users. > > Free software with a community around it and packaged in major distros > qualifies. If you haven't got that, talk to us to find out whether what > you've got qualifies, and if not, what you'd have to do to make it > qualify. > > Back when we accepted ivshmem, the out-of-tree parts it needs were well > below the "community & packaged" bar. But folks interested in it talked > to us, and the fact that it's in shows that QEMU maintainers decided > what they had then was enough. > > Unfortunately, we now have considerably less: Nahanni appears to be > dead. > > An apparently dead git repository you can study is not enough. The fact > that you hold an improved reimplementation privately is immaterial. So > is the (plausible) claim that others could also create a > reimplementation. > > >> If this server requires privileges: I don't trust it without an > >> audit. > >> > >> 4. Out-of-tree kernel uio driver required > > > > No, it is optional. > > Good to know. Would you be willing to send a patch to > ivshmem_device_spec.txt clarifying that? > > >> The device is "intended to be used with the provided UIO driver" > >> (ivshmem_device_spec.txt again). As far as I can tell, the "provided > >> UIO driver" is the one in the dead Nahanni repo. > >> > >> By now, you should be expecting this: I don't trust that one either. > >> > >> These concerns are all fixable, but it'll take serious work, and time. > >> Something like: > >> > >> * Find a maintainer for the device model > > I guess, we can find it into the DPDK.org community. > >> * Review and fix its code > >> > >> * Get the required kernel module upstream > > > > which module? uio, it is not required. > > > >> * Get all the required parts outside QEMU packaged in major distros, or > >> absorbed into QEMU > > > > Redhat did disable it. why? it is there in QEMU. > > Up to now, I've been wearing my QEMU hat. Let me exchange it for my Red > one for a bit. > > We (Red Hat) don't just package & ship metric tons of random free > software. We package & ship useful free software we can support for > many, many years. > > Sometimes, we find that we have to focus serious development resources > on making something useful supportable (Paolo mentioned qcow2). We > obviously can't focus on everything, though. > > Anyway, ivshmem didn't make the cut for RHEL-7.0. Sorry if that > inconveniences you. To get it into RHEL, you need to show it's both > useful and supportable. Building a community around it would go a long > way towards that. > > If you want to discuss this in more detail with us, you may want to try > communication channels provided by your RHEL subscription in addition to > the QEMU development mailing list. Don't be shy, you're paying for it! > > As always, I'm not speaking for myself, not my employer. > > Okay, wearing my QEMU hat again. > > >> In short, create a viable community around ivshmem, either within the > >> QEMU community, or separately but cooperating. > > > > At least, DPDK.org community is a community using it. > > Using something isn't the same as maintaining something. But it's a > necessary first step. > > [...] > > -- Thanks and regards, Jobin Raju George Final Year, Information Technology College of Engineering Pune Alternate e-mail: georgejr10.it@coep.ac.in --047d7b2e3d92b30bbb04fbb4501e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nahanni's poor current development coupled with virtIO= 's promising expansion was what encouraged us to explore virtIO-serial = [1] for inter-virtual machine communication. Though virtIO-serial as it is = isn't helpful for inter-VM communication, some work is needed for this = purpose and this is exactly what we (I and two of my fellow classmates) acc= omplished.

We haven't published it yet since we do need to polish yet for upst= reaming it and are planning do it in near future.


[1]: http://fedoraproje= ct.org/wiki/Features/VirtioSerial


On Fri,= Jun 13, 2014 at 2:16 PM, Markus Armbruster <armbru@redhat.com> wrote:
Some dropped quoted text restored.

Vincent JARDIN <vincent.jard= in@6wind.com> writes:

> Markus,
>
> see inline (I am not on all mailing list, please, keep the cc list). >
>> Sure! =C2=A0The reasons for my dislike range from practical to
>> philosophical.
>>
>> My practical concerns include:
>>
>> 1. ivshmem code needs work, but has no maintainer
> See David's contributions:
> =C2=A0 http://patchwork.ozlabs.org/patch/358750/

We're grateful for David's patch for qemu-char.c, but this isn'= t ivshmem
maintenance, yet.

>> =C2=A0 - Error handling is generally poor. =C2=A0For instance, &qu= ot;device_add
>> =C2=A0 =C2=A0 ivshmem" kills your guest instantly.
>>
>> =C2=A0 - More subjectively, I don't trust the code to be robus= t against
>> =C2=A0 =C2=A0 abuse by our own guest, or the other guests sharing = the memory.
>> =C2=A0 =C2=A0 Convincing me would take a code audit.
>>
>> =C2=A0 - MAINTAINERS doesn't cover ivshmem.c.
>>
>> =C2=A0 - The last non-trivial commit that isn't obviously part= of some
>> =C2=A0 =C2=A0 tree-wide infrastructure or cleanup work is from Sep= tember 2012
>> =C2=A0 =C2=A0 (commit c08ba66).
>>
>> 2. There is no libvirt support
>
> One can use qemu without libvivrt.

You asked me for my reasons for disliking ivshmem. =C2=A0This is one.

Sure, I can drink my water through a straw while standing on one foot,
but that doesn't mean I have to like it. =C2=A0And me not liking it doe= sn't
mean the next guy shouldn't like it. =C2=A0To each their own.

>> 3. Out-of-tree server program required for full functionality
>>
>> =C2=A0 Interrupts require a "shared memory server" runni= ng in the host (see
>> =C2=A0 docs/specs/ivshmem_device_spec.txt). =C2=A0It doesn't t= ell where to find
>> =C2=A0 one. =C2=A0The initial commit 6cbf4c8 points to
>> =C2=A0 <www.gitorious.org/nahanni>. =C2=A0That repository's last= commit is from
>> =C2=A0 September 2012. =C2=A0He's dead, Jim.
>>
>> =C2=A0 ivshmem_device_spec.txt is silent on what the server is sup= posed to
>> =C2=A0 do.
>
> We have the source code, it provides the documentation to write our > own better server program.

Good for you. =C2=A0Not good enough for the QEMU community.

QEMU features requiring on out-of-tree software to be useful are fine,
as long as said out-of-tree software is readily available to QEMU
developers and users.

Free software with a community around it and packaged in major distros
qualifies. =C2=A0If you haven't got that, talk to us to find out whethe= r what
you've got qualifies, and if not, what you'd have to do to make it<= br> qualify.

Back when we accepted ivshmem, the out-of-tree parts it needs were well
below the "community & packaged" bar. =C2=A0But folks interes= ted in it talked
to us, and the fact that it's in shows that QEMU maintainers decided what they had then was enough.

Unfortunately, we now have considerably less: Nahanni appears to be
dead.

An apparently dead git repository you can study is not enough. =C2=A0The fa= ct
that you hold an improved reimplementation privately is immaterial. =C2=A0S= o
is the (plausible) claim that others could also create a
reimplementation.

>> =C2=A0 If this server requires privileges: I don't trust it wi= thout an
>> =C2=A0 audit.
>>
>> 4. Out-of-tree kernel uio driver required
>
> No, it is optional.

Good to know. =C2=A0Would you be willing to send a patch to
ivshmem_device_spec.txt clarifying that?

>> =C2=A0 The device is "intended to be used with the provided U= IO driver"
>> =C2=A0 (ivshmem_device_spec.txt again). =C2=A0As far as I can tell= , the "provided
>> =C2=A0 UIO driver" is the one in the dead Nahanni repo.
>>
>> =C2=A0 By now, you should be expecting this: I don't trust tha= t one either.
>>
>> These concerns are all fixable, but it'll take serious work, a= nd time.
>> Something like:
>>
>> * Find a maintainer for the device model
> I guess, we can find it into the DPDK.org community.
>> * Review and fix its code
>>
>> * Get the required kernel module upstream
>
> which module? uio, it is not required.
>
>> * Get all the required parts outside QEMU packaged in major distro= s, or
>> =C2=A0 =C2=A0absorbed into QEMU
>
> Redhat did disable it. why? it is there in QEMU.

Up to now, I've been wearing my QEMU hat. =C2=A0Let me exchange it for = my Red
one for a bit.

We (Red Hat) don't just package & ship metric tons of random free software. =C2=A0We package & ship useful free software we can support f= or
many, many years.

Sometimes, we find that we have to focus serious development resources
on making something useful supportable (Paolo mentioned qcow2). =C2=A0We obviously can't focus on everything, though.

Anyway, ivshmem didn't make the cut for RHEL-7.0. =C2=A0Sorry if that inconveniences you. =C2=A0To get it into RHEL, you need to show it's bo= th
useful and supportable. =C2=A0Building a community around it would go a lon= g
way towards that.

If you want to discuss this in more detail with us, you may want to try
communication channels provided by your RHEL subscription in addition to the QEMU development mailing list. =C2=A0Don't be shy, you're payin= g for it!

As always, I'm not speaking for myself, not my employer.

Okay, wearing my QEMU hat again.

>> In short, create a viable community around ivshmem, either within = the
>> QEMU community, or separately but cooperating.
>
> At least, DPDK.org community is a community using it.

Using something isn't the same as maintaining something. =C2=A0But it&#= 39;s a
necessary first step.

[...]




--

Thanks and regards,

Jobin Raju George

Final Year, Information Technology

College of Engineering Pune

Alternate e-mail:=C2=A0georgejr10.it@coep.a= c.in

--047d7b2e3d92b30bbb04fbb4501e-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43737) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvNnk-0006EN-Ov for qemu-devel@nongnu.org; Fri, 13 Jun 2014 05:29:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WvNni-0008DP-Jl for qemu-devel@nongnu.org; Fri, 13 Jun 2014 05:29:36 -0400 Received: from mail-ob0-x22d.google.com ([2607:f8b0:4003:c01::22d]:33446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvNni-0008DH-CG for qemu-devel@nongnu.org; Fri, 13 Jun 2014 05:29:34 -0400 Received: by mail-ob0-f173.google.com with SMTP id va2so2633736obc.4 for ; Fri, 13 Jun 2014 02:29:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87ppidnqmy.fsf@blackfin.pond.sub.org> References: <20140610184818.2e490419@nbschild1> <53978375.6090707@6wind.com> <87ppie1v4r.fsf@blackfin.pond.sub.org> <20140612094413.15e56938@nbschild1> <87vbs6qjhj.fsf_-_@blackfin.pond.sub.org> <5399CF09.8030803@6wind.com> <87ppidnqmy.fsf@blackfin.pond.sub.org> Date: Fri, 13 Jun 2014 14:59:33 +0530 Message-ID: From: Jobin Raju George Content-Type: multipart/alternative; boundary=047d7b2e3d92b30bbb04fbb4501e Subject: Re: [Qemu-devel] Why I advise against using ivshmem List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Henning Schild , kvm@vger.kernel.org, QEMU Developers , David Marchand , sagar patni , virtualization@lists.linux-foundation.org, Vincent JARDIN --047d7b2e3d92b30bbb04fbb4501e Content-Type: text/plain; charset=UTF-8 Nahanni's poor current development coupled with virtIO's promising expansion was what encouraged us to explore virtIO-serial [1] for inter-virtual machine communication. Though virtIO-serial as it is isn't helpful for inter-VM communication, some work is needed for this purpose and this is exactly what we (I and two of my fellow classmates) accomplished. We haven't published it yet since we do need to polish yet for upstreaming it and are planning do it in near future. [1]: http://fedoraproject.org/wiki/Features/VirtioSerial On Fri, Jun 13, 2014 at 2:16 PM, Markus Armbruster wrote: > Some dropped quoted text restored. > > Vincent JARDIN writes: > > > Markus, > > > > see inline (I am not on all mailing list, please, keep the cc list). > > > >> Sure! The reasons for my dislike range from practical to > >> philosophical. > >> > >> My practical concerns include: > >> > >> 1. ivshmem code needs work, but has no maintainer > > See David's contributions: > > http://patchwork.ozlabs.org/patch/358750/ > > We're grateful for David's patch for qemu-char.c, but this isn't ivshmem > maintenance, yet. > > >> - Error handling is generally poor. For instance, "device_add > >> ivshmem" kills your guest instantly. > >> > >> - More subjectively, I don't trust the code to be robust against > >> abuse by our own guest, or the other guests sharing the memory. > >> Convincing me would take a code audit. > >> > >> - MAINTAINERS doesn't cover ivshmem.c. > >> > >> - The last non-trivial commit that isn't obviously part of some > >> tree-wide infrastructure or cleanup work is from September 2012 > >> (commit c08ba66). > >> > >> 2. There is no libvirt support > > > > One can use qemu without libvivrt. > > You asked me for my reasons for disliking ivshmem. This is one. > > Sure, I can drink my water through a straw while standing on one foot, > but that doesn't mean I have to like it. And me not liking it doesn't > mean the next guy shouldn't like it. To each their own. > > >> 3. Out-of-tree server program required for full functionality > >> > >> Interrupts require a "shared memory server" running in the host (see > >> docs/specs/ivshmem_device_spec.txt). It doesn't tell where to find > >> one. The initial commit 6cbf4c8 points to > >> . That repository's last commit is from > >> September 2012. He's dead, Jim. > >> > >> ivshmem_device_spec.txt is silent on what the server is supposed to > >> do. > > > > We have the source code, it provides the documentation to write our > > own better server program. > > Good for you. Not good enough for the QEMU community. > > QEMU features requiring on out-of-tree software to be useful are fine, > as long as said out-of-tree software is readily available to QEMU > developers and users. > > Free software with a community around it and packaged in major distros > qualifies. If you haven't got that, talk to us to find out whether what > you've got qualifies, and if not, what you'd have to do to make it > qualify. > > Back when we accepted ivshmem, the out-of-tree parts it needs were well > below the "community & packaged" bar. But folks interested in it talked > to us, and the fact that it's in shows that QEMU maintainers decided > what they had then was enough. > > Unfortunately, we now have considerably less: Nahanni appears to be > dead. > > An apparently dead git repository you can study is not enough. The fact > that you hold an improved reimplementation privately is immaterial. So > is the (plausible) claim that others could also create a > reimplementation. > > >> If this server requires privileges: I don't trust it without an > >> audit. > >> > >> 4. Out-of-tree kernel uio driver required > > > > No, it is optional. > > Good to know. Would you be willing to send a patch to > ivshmem_device_spec.txt clarifying that? > > >> The device is "intended to be used with the provided UIO driver" > >> (ivshmem_device_spec.txt again). As far as I can tell, the "provided > >> UIO driver" is the one in the dead Nahanni repo. > >> > >> By now, you should be expecting this: I don't trust that one either. > >> > >> These concerns are all fixable, but it'll take serious work, and time. > >> Something like: > >> > >> * Find a maintainer for the device model > > I guess, we can find it into the DPDK.org community. > >> * Review and fix its code > >> > >> * Get the required kernel module upstream > > > > which module? uio, it is not required. > > > >> * Get all the required parts outside QEMU packaged in major distros, or > >> absorbed into QEMU > > > > Redhat did disable it. why? it is there in QEMU. > > Up to now, I've been wearing my QEMU hat. Let me exchange it for my Red > one for a bit. > > We (Red Hat) don't just package & ship metric tons of random free > software. We package & ship useful free software we can support for > many, many years. > > Sometimes, we find that we have to focus serious development resources > on making something useful supportable (Paolo mentioned qcow2). We > obviously can't focus on everything, though. > > Anyway, ivshmem didn't make the cut for RHEL-7.0. Sorry if that > inconveniences you. To get it into RHEL, you need to show it's both > useful and supportable. Building a community around it would go a long > way towards that. > > If you want to discuss this in more detail with us, you may want to try > communication channels provided by your RHEL subscription in addition to > the QEMU development mailing list. Don't be shy, you're paying for it! > > As always, I'm not speaking for myself, not my employer. > > Okay, wearing my QEMU hat again. > > >> In short, create a viable community around ivshmem, either within the > >> QEMU community, or separately but cooperating. > > > > At least, DPDK.org community is a community using it. > > Using something isn't the same as maintaining something. But it's a > necessary first step. > > [...] > > -- Thanks and regards, Jobin Raju George Final Year, Information Technology College of Engineering Pune Alternate e-mail: georgejr10.it@coep.ac.in --047d7b2e3d92b30bbb04fbb4501e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nahanni's poor current development coupled with virtIO= 's promising expansion was what encouraged us to explore virtIO-serial = [1] for inter-virtual machine communication. Though virtIO-serial as it is = isn't helpful for inter-VM communication, some work is needed for this = purpose and this is exactly what we (I and two of my fellow classmates) acc= omplished.

We haven't published it yet since we do need to polish yet for upst= reaming it and are planning do it in near future.


[1]: http://fedoraproje= ct.org/wiki/Features/VirtioSerial


On Fri,= Jun 13, 2014 at 2:16 PM, Markus Armbruster <armbru@redhat.com> wrote:
Some dropped quoted text restored.

Vincent JARDIN <vincent.jard= in@6wind.com> writes:

> Markus,
>
> see inline (I am not on all mailing list, please, keep the cc list). >
>> Sure! =C2=A0The reasons for my dislike range from practical to
>> philosophical.
>>
>> My practical concerns include:
>>
>> 1. ivshmem code needs work, but has no maintainer
> See David's contributions:
> =C2=A0 http://patchwork.ozlabs.org/patch/358750/

We're grateful for David's patch for qemu-char.c, but this isn'= t ivshmem
maintenance, yet.

>> =C2=A0 - Error handling is generally poor. =C2=A0For instance, &qu= ot;device_add
>> =C2=A0 =C2=A0 ivshmem" kills your guest instantly.
>>
>> =C2=A0 - More subjectively, I don't trust the code to be robus= t against
>> =C2=A0 =C2=A0 abuse by our own guest, or the other guests sharing = the memory.
>> =C2=A0 =C2=A0 Convincing me would take a code audit.
>>
>> =C2=A0 - MAINTAINERS doesn't cover ivshmem.c.
>>
>> =C2=A0 - The last non-trivial commit that isn't obviously part= of some
>> =C2=A0 =C2=A0 tree-wide infrastructure or cleanup work is from Sep= tember 2012
>> =C2=A0 =C2=A0 (commit c08ba66).
>>
>> 2. There is no libvirt support
>
> One can use qemu without libvivrt.

You asked me for my reasons for disliking ivshmem. =C2=A0This is one.

Sure, I can drink my water through a straw while standing on one foot,
but that doesn't mean I have to like it. =C2=A0And me not liking it doe= sn't
mean the next guy shouldn't like it. =C2=A0To each their own.

>> 3. Out-of-tree server program required for full functionality
>>
>> =C2=A0 Interrupts require a "shared memory server" runni= ng in the host (see
>> =C2=A0 docs/specs/ivshmem_device_spec.txt). =C2=A0It doesn't t= ell where to find
>> =C2=A0 one. =C2=A0The initial commit 6cbf4c8 points to
>> =C2=A0 <www.gitorious.org/nahanni>. =C2=A0That repository's last= commit is from
>> =C2=A0 September 2012. =C2=A0He's dead, Jim.
>>
>> =C2=A0 ivshmem_device_spec.txt is silent on what the server is sup= posed to
>> =C2=A0 do.
>
> We have the source code, it provides the documentation to write our > own better server program.

Good for you. =C2=A0Not good enough for the QEMU community.

QEMU features requiring on out-of-tree software to be useful are fine,
as long as said out-of-tree software is readily available to QEMU
developers and users.

Free software with a community around it and packaged in major distros
qualifies. =C2=A0If you haven't got that, talk to us to find out whethe= r what
you've got qualifies, and if not, what you'd have to do to make it<= br> qualify.

Back when we accepted ivshmem, the out-of-tree parts it needs were well
below the "community & packaged" bar. =C2=A0But folks interes= ted in it talked
to us, and the fact that it's in shows that QEMU maintainers decided what they had then was enough.

Unfortunately, we now have considerably less: Nahanni appears to be
dead.

An apparently dead git repository you can study is not enough. =C2=A0The fa= ct
that you hold an improved reimplementation privately is immaterial. =C2=A0S= o
is the (plausible) claim that others could also create a
reimplementation.

>> =C2=A0 If this server requires privileges: I don't trust it wi= thout an
>> =C2=A0 audit.
>>
>> 4. Out-of-tree kernel uio driver required
>
> No, it is optional.

Good to know. =C2=A0Would you be willing to send a patch to
ivshmem_device_spec.txt clarifying that?

>> =C2=A0 The device is "intended to be used with the provided U= IO driver"
>> =C2=A0 (ivshmem_device_spec.txt again). =C2=A0As far as I can tell= , the "provided
>> =C2=A0 UIO driver" is the one in the dead Nahanni repo.
>>
>> =C2=A0 By now, you should be expecting this: I don't trust tha= t one either.
>>
>> These concerns are all fixable, but it'll take serious work, a= nd time.
>> Something like:
>>
>> * Find a maintainer for the device model
> I guess, we can find it into the DPDK.org community.
>> * Review and fix its code
>>
>> * Get the required kernel module upstream
>
> which module? uio, it is not required.
>
>> * Get all the required parts outside QEMU packaged in major distro= s, or
>> =C2=A0 =C2=A0absorbed into QEMU
>
> Redhat did disable it. why? it is there in QEMU.

Up to now, I've been wearing my QEMU hat. =C2=A0Let me exchange it for = my Red
one for a bit.

We (Red Hat) don't just package & ship metric tons of random free software. =C2=A0We package & ship useful free software we can support f= or
many, many years.

Sometimes, we find that we have to focus serious development resources
on making something useful supportable (Paolo mentioned qcow2). =C2=A0We obviously can't focus on everything, though.

Anyway, ivshmem didn't make the cut for RHEL-7.0. =C2=A0Sorry if that inconveniences you. =C2=A0To get it into RHEL, you need to show it's bo= th
useful and supportable. =C2=A0Building a community around it would go a lon= g
way towards that.

If you want to discuss this in more detail with us, you may want to try
communication channels provided by your RHEL subscription in addition to the QEMU development mailing list. =C2=A0Don't be shy, you're payin= g for it!

As always, I'm not speaking for myself, not my employer.

Okay, wearing my QEMU hat again.

>> In short, create a viable community around ivshmem, either within = the
>> QEMU community, or separately but cooperating.
>
> At least, DPDK.org community is a community using it.

Using something isn't the same as maintaining something. =C2=A0But it&#= 39;s a
necessary first step.

[...]




--

Thanks and regards,

Jobin Raju George

Final Year, Information Technology

College of Engineering Pune

Alternate e-mail:=C2=A0georgejr10.it@coep.a= c.in

--047d7b2e3d92b30bbb04fbb4501e--