Patchwork [1/3] qemu-system: new package

login
register
mail settings
Submitter Gustavo Zacarias
Date May 3, 2014, 8:20 p.m.
Message ID <1399148415-27648-1-git-send-email-gustavo@zacarias.com.ar>
Download mbox | patch
Permalink /patch/345358/
State Changes Requested
Headers show

Comments

Gustavo Zacarias - May 3, 2014, 8:20 p.m.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/Config.in.host             |  1 +
 package/qemu-system/Config.in.host | 30 ++++++++++++++++++
 package/qemu-system/qemu-system.mk | 64 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 95 insertions(+)
 create mode 100644 package/qemu-system/Config.in.host
 create mode 100644 package/qemu-system/qemu-system.mk
Thomas Petazzoni - Oct. 12, 2014, 3:17 p.m.
Dear Gustavo Zacarias,

On Sat,  3 May 2014 17:20:13 -0300, Gustavo Zacarias wrote:
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  package/Config.in.host             |  1 +
>  package/qemu-system/Config.in.host | 30 ++++++++++++++++++
>  package/qemu-system/qemu-system.mk | 64 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 95 insertions(+)
>  create mode 100644 package/qemu-system/Config.in.host
>  create mode 100644 package/qemu-system/qemu-system.mk

We discussed this patch series during the Buildroot meeting. PATCH 3/3
is Superseded, as you have updated the Qemu defconfigs many time since
then.

Regarding PATCH 1/3 and PATCH 2/3, we continue to believe it should be
part of the qemu package itself, and not a separate qemu-system. Since
I know you are not interested in doing this work, Yann E. Morin has
said he was interested in doing this, once his current patch series
adding support for qemu-system on the target has been merged.

Consequently, I will mark your patches as 'Changes Requested' in
patchwork. Of course, if in the mean time you change your mind and
decide to implement host qemu-system as part of the qemu package, we'd
be happy to receive your patches! :-)

Best regards,

Thomas
Gustavo Zacarias - Oct. 12, 2014, 7:03 p.m.
On 10/12/2014 12:17 PM, Thomas Petazzoni wrote:

> We discussed this patch series during the Buildroot meeting. PATCH 3/3
> is Superseded, as you have updated the Qemu defconfigs many time since
> then.
> 
> Regarding PATCH 1/3 and PATCH 2/3, we continue to believe it should be
> part of the qemu package itself, and not a separate qemu-system. Since
> I know you are not interested in doing this work, Yann E. Morin has
> said he was interested in doing this, once his current patch series
> adding support for qemu-system on the target has been merged.
> 
> Consequently, I will mark your patches as 'Changes Requested' in
> patchwork. Of course, if in the mean time you change your mind and
> decide to implement host qemu-system as part of the qemu package, we'd
> be happy to receive your patches! :-)

I don't agree on the reasoning:
You can't use different versions for host and non-host packages in a
clean way: that alone and the fact that no single qemu version can cover
all of the emulations would make the single package pointless.
It's all fine and nice to strive to get qemu fixed but it's an
unrealistic objective, new architectures and variants together with old
emulations that seldomly are used/tested will continue to make this a
moving target.
Time and time again this has proven to be the case so leaving a fixed
version for the package will make it pointless, we can just tell people
to use some random distro version and get the same result which would
render the host package with no sense to be.
And changing the package version for the target because the host version
needs some special care plays into the changing results arena.
Granted it's not a common use-case to have both, but it's doing it
regarless.
You want all emulations to work, not just some depending on weather,
wind and pollen count.
So on my side i'm not planning to do anything with this decision.
Regards.
Arnout Vandecappelle - Oct. 15, 2014, 5:01 p.m.
On 12/10/14 21:03, Gustavo Zacarias wrote:
> On 10/12/2014 12:17 PM, Thomas Petazzoni wrote:
> 
>> We discussed this patch series during the Buildroot meeting. PATCH 3/3
>> is Superseded, as you have updated the Qemu defconfigs many time since
>> then.
>>
>> Regarding PATCH 1/3 and PATCH 2/3, we continue to believe it should be
>> part of the qemu package itself, and not a separate qemu-system. Since
>> I know you are not interested in doing this work, Yann E. Morin has
>> said he was interested in doing this, once his current patch series
>> adding support for qemu-system on the target has been merged.
>>
>> Consequently, I will mark your patches as 'Changes Requested' in
>> patchwork. Of course, if in the mean time you change your mind and
>> decide to implement host qemu-system as part of the qemu package, we'd
>> be happy to receive your patches! :-)
> 
> I don't agree on the reasoning:
> You can't use different versions for host and non-host packages in a
> clean way: 

 Can you explain why not?

 You cannot use different versions for qemu-user and qemu-system in a clean way
if they're not different packages. But host and target versions don't need to be
the same. At least, I see code in pkg-generic.mk to handle that.

 And I do think we want to keep qemu-user and qemu-system at the same version,
right? Or does it happen that you need different versions for these as well?

 The real question is how to make the version depend on the values in
BR2_PACKAGE_QEMU_CUSTOM_TARGETS. But that is not the concern of your patch.


 Regards,
 Arnout


> that alone and the fact that no single qemu version can cover
> all of the emulations would make the single package pointless.
> It's all fine and nice to strive to get qemu fixed but it's an
> unrealistic objective, new architectures and variants together with old
> emulations that seldomly are used/tested will continue to make this a
> moving target.
> Time and time again this has proven to be the case so leaving a fixed
> version for the package will make it pointless, we can just tell people
> to use some random distro version and get the same result which would
> render the host package with no sense to be.
> And changing the package version for the target because the host version
> needs some special care plays into the changing results arena.
> Granted it's not a common use-case to have both, but it's doing it
> regarless.
> You want all emulations to work, not just some depending on weather,
> wind and pollen count.
> So on my side i'm not planning to do anything with this decision.
> Regards.
> 
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 
>
Gustavo Zacarias - Oct. 16, 2014, 1:53 p.m.
On 10/15/2014 02:01 PM, Arnout Vandecappelle wrote:

>  Can you explain why not?
> 
>  You cannot use different versions for qemu-user and qemu-system in a clean way
> if they're not different packages. But host and target versions don't need to be
> the same. At least, I see code in pkg-generic.mk to handle that.

Well, not really, for example try modifying package/e2fsprogs.mk:
HOST_E2FSPROGS_VERSION = 1.42.13

And build both, see what happens.
Even try a make source with that.

>  And I do think we want to keep qemu-user and qemu-system at the same version,
> right? Or does it happen that you need different versions for these as well?
> 
>  The real question is how to make the version depend on the values in
> BR2_PACKAGE_QEMU_CUSTOM_TARGETS. But that is not the concern of your patch.

No, that's a wrong assumption.
For example qemu_mpc8544ds_defconfig doesn't work with the latest 2.1.2
qemu, however other qemu ppc sample defconfigs do (in fact no 2.1.x
version).
And the qemu config should dictate what's the best version for each -
not necessarily the latest, you can't make host-qemu-user depend on that
since it's a platform decision, not an arch one.
If you want to stick with "the one that works for everything" you
potentially miss the opportunity for new arch and/or platform support.
So even if target != host version is fixed/possible you'll still clash
on host-qemu (user) vs. host-qemu (system) versions since you might want
to do the perl module dance (original purpose of host-qemu) vs. platform
emulation.
It's nice to keep everything in one package, but it's not feasible to do
so in a coherent way for this case in particular.
If you can't get the leash out of the qemu version there's no point in
building so for the emulation, sometimes you'll ship every single qemu
config working, sometimes you wont - and that's my quarrel, everyone is
perfect-this perfect-that but all of the sudden this would be acceptable?
Like i said it would be the same as $RANDOM distro qemu.
Regards.
Arnout Vandecappelle - Oct. 17, 2014, 10:47 p.m.
On 16/10/14 15:53, Gustavo Zacarias wrote:
> On 10/15/2014 02:01 PM, Arnout Vandecappelle wrote:
> 
>>  Can you explain why not?
>>
>>  You cannot use different versions for qemu-user and qemu-system in a clean way
>> if they're not different packages. But host and target versions don't need to be
>> the same. At least, I see code in pkg-generic.mk to handle that.
> 
> Well, not really, for example try modifying package/e2fsprogs.mk:
> HOST_E2FSPROGS_VERSION = 1.42.13
> 
> And build both, see what happens.
> Even try a make source with that.

 Yeah, OK, you have to set the HOST_FOO_SOURCE explicitly as well due to a
little shortcoming in the infrastructure, but I don't think that should be a
showstopper.

> 
>>  And I do think we want to keep qemu-user and qemu-system at the same version,
>> right? Or does it happen that you need different versions for these as well?
>>
>>  The real question is how to make the version depend on the values in
>> BR2_PACKAGE_QEMU_CUSTOM_TARGETS. But that is not the concern of your patch.
> 
> No, that's a wrong assumption.
> For example qemu_mpc8544ds_defconfig doesn't work with the latest 2.1.2
> qemu, however other qemu ppc sample defconfigs do (in fact no 2.1.x
> version).

 Yes, you're right, the host-qemu version should be dictated by a config option,
not derived automatically.


> And the qemu config should dictate what's the best version for each -
> not necessarily the latest, you can't make host-qemu-user depend on that
> since it's a platform decision, not an arch one.
> If you want to stick with "the one that works for everything" you

 AFAIK nobody claims that there should be one version that works for everything
- possibly there should even be some version config option for the target qemu.
The only problem we see is to have a separate qemu-system and qemu-user package.


> potentially miss the opportunity for new arch and/or platform support.
> So even if target != host version is fixed/possible you'll still clash
> on host-qemu (user) vs. host-qemu (system) versions since you might want
> to do the perl module dance (original purpose of host-qemu) vs. platform
> emulation.

 This one I don't understand. If you need version 2.0.2 for host-qemu-system,
then surely you also need this version for host-qemu-user? So what is the point
of treating them as separate packages? Isn't it much easier to build qemu-user
and qemu-system in one shot (like how it's done for the target qemu)?


 Regards,
 Arnout


> It's nice to keep everything in one package, but it's not feasible to do
> so in a coherent way for this case in particular.
> If you can't get the leash out of the qemu version there's no point in
> building so for the emulation, sometimes you'll ship every single qemu
> config working, sometimes you wont - and that's my quarrel, everyone is
> perfect-this perfect-that but all of the sudden this would be acceptable?
> Like i said it would be the same as $RANDOM distro qemu.
> Regards.
Gustavo Zacarias - Oct. 18, 2014, 1:14 a.m.
On 10/17/2014 07:47 PM, Arnout Vandecappelle wrote:

>> potentially miss the opportunity for new arch and/or platform support.
>> So even if target != host version is fixed/possible you'll still clash
>> on host-qemu (user) vs. host-qemu (system) versions since you might want
>> to do the perl module dance (original purpose of host-qemu) vs. platform
>> emulation.
> 
>  This one I don't understand. If you need version 2.0.2 for host-qemu-system,
> then surely you also need this version for host-qemu-user? So what is the point
> of treating them as separate packages? Isn't it much easier to build qemu-user
> and qemu-system in one shot (like how it's done for the target qemu)?

The only shared code in qemu for user vs. system is just basically CPU
emulation.
For system you've got all of the hardware (audio/ hw/ net/ directories
and so on) which isn't used by user at all.
For user it deals with what we can call "ABI" (userland, linux-user/ dir
in qemu) which isn't used by system at all, and has arch bits as well.
When there are system emulations broken with the latest version of qemu
it isn't necessarily a problem with the cpu emulation, the same can
happen to user emulation without affecting system.
So if you're like 100% sure user both will work right if system does for
X version go ahead, i don't think it's a safe assumption.
Just google around a bit:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1284344
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668658
Regards.
Arnout Vandecappelle - Oct. 19, 2014, 8:27 p.m.
On 18/10/14 03:14, Gustavo Zacarias wrote:
> On 10/17/2014 07:47 PM, Arnout Vandecappelle wrote:
> 
>>> potentially miss the opportunity for new arch and/or platform support.
>>> So even if target != host version is fixed/possible you'll still clash
>>> on host-qemu (user) vs. host-qemu (system) versions since you might want
>>> to do the perl module dance (original purpose of host-qemu) vs. platform
>>> emulation.
>>
>>  This one I don't understand. If you need version 2.0.2 for host-qemu-system,
>> then surely you also need this version for host-qemu-user? So what is the point
>> of treating them as separate packages? Isn't it much easier to build qemu-user
>> and qemu-system in one shot (like how it's done for the target qemu)?
> 
> The only shared code in qemu for user vs. system is just basically CPU
> emulation.
> For system you've got all of the hardware (audio/ hw/ net/ directories
> and so on) which isn't used by user at all.
> For user it deals with what we can call "ABI" (userland, linux-user/ dir
> in qemu) which isn't used by system at all, and has arch bits as well.
> When there are system emulations broken with the latest version of qemu
> it isn't necessarily a problem with the cpu emulation, the same can
> happen to user emulation without affecting system.
> So if you're like 100% sure user both will work right if system does for
> X version go ahead, i don't think it's a safe assumption.
> Just google around a bit:
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1284344
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668658

 So what I hear you say is that there really is a case for specifying the
qemu-user and qemu-system version separately, and that that's what this whole
discussion really is about. And I guess you may want to build at the same time a
host-qemu-user of one version and a host-qemu-system of another version, correct?

 Still, the .mk file of qemu-user and qemu-system are 90% the same. It would be
nice to be able to factor that out somehow. However, it makes complete sense to
have them as separate packages first and merge them later.

 So the question is: is the need for separate host-qemu-system and
host-qemu-user versions more important than the additional complexity of
specifying a nearly-identical .mk file twice?

 Regards,
 Arnout
Thomas Petazzoni - Oct. 19, 2014, 8:54 p.m.
Dear Arnout Vandecappelle,

On Sun, 19 Oct 2014 22:27:11 +0200, Arnout Vandecappelle wrote:

> > The only shared code in qemu for user vs. system is just basically CPU
> > emulation.
> > For system you've got all of the hardware (audio/ hw/ net/ directories
> > and so on) which isn't used by user at all.
> > For user it deals with what we can call "ABI" (userland, linux-user/ dir
> > in qemu) which isn't used by system at all, and has arch bits as well.
> > When there are system emulations broken with the latest version of qemu
> > it isn't necessarily a problem with the cpu emulation, the same can
> > happen to user emulation without affecting system.
> > So if you're like 100% sure user both will work right if system does for
> > X version go ahead, i don't think it's a safe assumption.
> > Just google around a bit:
> > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1284344
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668658
> 
>  So what I hear you say is that there really is a case for specifying the
> qemu-user and qemu-system version separately, and that that's what this whole
> discussion really is about. And I guess you may want to build at the same time a
> host-qemu-user of one version and a host-qemu-system of another version, correct?
> 
>  Still, the .mk file of qemu-user and qemu-system are 90% the same. It would be
> nice to be able to factor that out somehow. However, it makes complete sense to
> have them as separate packages first and merge them later.
> 
>  So the question is: is the need for separate host-qemu-system and
> host-qemu-user versions more important than the additional complexity of
> specifying a nearly-identical .mk file twice?

Despite Gustavo's explanation, I'm not sure to see what is the need to
have a different version for host-qemu-system and host-qemu-user.

If a given version of host-qemu-system works for a given
architecture/platform, then surely, host-qemu-user should work for the
same architecture. The opposite is obviously not true, but it doesn't
matter much: we can keep whatever version gets host-qemu-system working.

Thomas
Gustavo Zacarias - Oct. 20, 2014, 1:53 a.m.
On 10/19/2014 05:54 PM, Thomas Petazzoni wrote:

> On Sun, 19 Oct 2014 22:27:11 +0200, Arnout Vandecappelle wrote:
> 
>>  So what I hear you say is that there really is a case for specifying the
>> qemu-user and qemu-system version separately, and that that's what this whole
>> discussion really is about. And I guess you may want to build at the same time a
>> host-qemu-user of one version and a host-qemu-system of another version, correct?
>>
>>  Still, the .mk file of qemu-user and qemu-system are 90% the same. It would be
>> nice to be able to factor that out somehow. However, it makes complete sense to
>> have them as separate packages first and merge them later.
>>
>>  So the question is: is the need for separate host-qemu-system and
>> host-qemu-user versions more important than the additional complexity of
>> specifying a nearly-identical .mk file twice?
> 
> Despite Gustavo's explanation, I'm not sure to see what is the need to
> have a different version for host-qemu-system and host-qemu-user.
> 
> If a given version of host-qemu-system works for a given
> architecture/platform, then surely, host-qemu-user should work for the
> same architecture. The opposite is obviously not true, but it doesn't
> matter much: we can keep whatever version gets host-qemu-system working.
> 
> Thomas

Arnout: yes, the package .mk could very much share everything that's
common among them yet still be a separate "package"
configuration/parameter-wise.
Thomas: you've got 3 scenarios, the cpu code is broken which won't
matter since both user/system will be broken for a given version, user
code broken which will matter to user only, hardware code broken which
will matter for system only.
Any of those can happen (even everything broken but it's basically the
same as the first option).
And if you're doing user-only for cross configure testing or whatnot
system won't be able to dictate which version you're using since it's a
config option outside of that scope.
To me it seems the decision was taken during the dev days with one-sided
arguments (against), but well life is like that sometimes.
The side effect is that it pushes my motivation to contribute to
buildroot to an all-time low (read that as you wish, in fact it may not
even matter).
Regards.
Arnout Vandecappelle - Oct. 20, 2014, 7:41 p.m.
On 20/10/14 03:53, Gustavo Zacarias wrote:
[snip]
> To me it seems the decision was taken during the dev days with one-sided
> arguments (against), but well life is like that sometimes.

 Well, there was nobody to provide counter-arguments. That's why I started the
discussion on the list.

 It's very clear that version selection is needed. It's not so clear that a
separate version is really needed for host-qemu-system and host-qemu-user, because:

 - there's a slightly larger chance that both system and user are broken;
 - we currently anyway don't have version selection for user;
 - we can change it later if required.

 On the other hand, it's also possible to merge the qemu-system package now and
refactor it back into a single package later. It wouldn't even require legacy
handling because the config symbols already start with BR2_PACKAGE_QEMU.

 So I'd propose to give Yann some time to produce a unified qemu package, but if
it doesn't come we can still merge your original patch.

> The side effect is that it pushes my motivation to contribute to
> buildroot to an all-time low (read that as you wish, in fact it may not
> even matter).

 Since you're the #1 buildroot contributor and have been for some time now, it
really does matter!


 Regards,
 Arnout
Thomas Petazzoni - Oct. 20, 2014, 9:16 p.m.
Dear Arnout Vandecappelle,

On Mon, 20 Oct 2014 21:41:34 +0200, Arnout Vandecappelle wrote:

>  Well, there was nobody to provide counter-arguments. That's why I started the
> discussion on the list.
> 
>  It's very clear that version selection is needed. It's not so clear that a
> separate version is really needed for host-qemu-system and host-qemu-user, because:
> 
>  - there's a slightly larger chance that both system and user are broken;
>  - we currently anyway don't have version selection for user;
>  - we can change it later if required.
> 
>  On the other hand, it's also possible to merge the qemu-system package now and
> refactor it back into a single package later. It wouldn't even require legacy
> handling because the config symbols already start with BR2_PACKAGE_QEMU.
> 
>  So I'd propose to give Yann some time to produce a unified qemu package, but if
> it doesn't come we can still merge your original patch.

I agree. Nothing is set in stone. At first sight, I don't really see a
reason to have a separate version for host-qemu-user and
host-qemu-system, so let's implement something that uses the same
version for both, and if reality proves that it was a bad choice, it
will also be time to change.

> > The side effect is that it pushes my motivation to contribute to
> > buildroot to an all-time low (read that as you wish, in fact it may not
> > even matter).
> 
>  Since you're the #1 buildroot contributor and have been for some time now, it
> really does matter!

Yes, it clearly matters. I'm a bit sad to see that this specific story
has affected your motivation. However, on this story, you had your own
idea, and basically rejected the comments that were made. That's not
really the best way to push things forward: maybe doing a concession
sometimes helps, and thanks to this concession, you might prove at a
later point that people were wrong and you were right from the
beginning :)

Best regards,

Thomas
Gustavo Zacarias - Oct. 20, 2014, 10:45 p.m.
On 10/20/2014 06:16 PM, Thomas Petazzoni wrote:

>>> The side effect is that it pushes my motivation to contribute to
>>> buildroot to an all-time low (read that as you wish, in fact it may not
>>> even matter).
>>
>>  Since you're the #1 buildroot contributor and have been for some time now, it
>> really does matter!
> 
> Yes, it clearly matters. I'm a bit sad to see that this specific story
> has affected your motivation. However, on this story, you had your own
> idea, and basically rejected the comments that were made. That's not
> really the best way to push things forward: maybe doing a concession
> sometimes helps, and thanks to this concession, you might prove at a
> later point that people were wrong and you were right from the
> beginning :)

The same can be said the opposite way don't you think?
This patchset has been sitting for almost a year now with no action on
the counterproposal from anyone.
The likely outcome is that the feature will still be missing until the
next release cycle.
Either the feature is not interesting and/or wanted, or contributors
just lack time, with my time being wasted, waiting (possibly not very
patiently at times) for someone else to follow-up on the alternative.

I won't make a concession on this because i really don't believe it's
the proper course of action, it's that simple, deal with it.
It's not that i'm stubborn, i've changed opinion in many occasions, and
i'm not seeking to "rub it off" - if i wanted to do so i could just say
"hashes" which i've proposed years ago with the idea being very much
rejected at the time - i'm not interested in that.
It could be well thought-out from the start without the need to fix
issues that were foreseen later.

It's dissapointing to just sum up commits doing banal stuff even if
they're important, to then get the cold shoulder when what i feel are
interesting or progressive ideas get delayed and/or rejected.
My feeling is that i'm just wasting my time if i make any serious effort
to improve things, so basically i give up.
At this point i would have hoped that i've earned some trust with my
technical choices, but it feels like not.
That doesn't mean i want a blank check on decisions, don't get that
interpretation out of it.

In the end it's not the number of commits that count, that's not an
indication of who's #1, #3 or anything, it may be fun but that's it.
The momentum is what makes projects great.
And mine wrt buildroot has been neutralized, i'll just care about my
little ranch: no autobuild fixing except what i break, no improvements
except for what i care, no ACKs, no Tested-bys, no #buildroot IRC, no
opinions and so on.
Time will tell if i feel like getting back to that or i'll just dial
down the notch on general involvement permanently (there's a saying
which i think is quite universal "never say never").
Sometimes you win sometimes you lose, in both the project and personal
levels.

I hope i've articulated this mail correctly.
Regards.
Thomas Petazzoni - Oct. 21, 2014, 7:16 a.m.
Dear Gustavo Zacarias,

On Mon, 20 Oct 2014 19:45:06 -0300, Gustavo Zacarias wrote:

> > Yes, it clearly matters. I'm a bit sad to see that this specific story
> > has affected your motivation. However, on this story, you had your own
> > idea, and basically rejected the comments that were made. That's not
> > really the best way to push things forward: maybe doing a concession
> > sometimes helps, and thanks to this concession, you might prove at a
> > later point that people were wrong and you were right from the
> > beginning :)
> 
> The same can be said the opposite way don't you think?

True in some way. But in another way, doing the concession on what gets
merged means reducing the "quality" of what we merge. Is this really
what we want? If something doesn't comply with the Buildroot coding
style and/or principles, should we merge it just because it has been
sitting there since one year?

> This patchset has been sitting for almost a year now with no action on
> the counterproposal from anyone.
> The likely outcome is that the feature will still be missing until the
> next release cycle.

I agree this isn't nice. But again, if there is a pending patch that
doesn't satisfy a majority of developers, should we merge it simply
because it has been pending for a long time? I'm sure you would agree
that we should not merge such a patch, even if that means leaving the
feature out of the tree for a while.

> I won't make a concession on this because i really don't believe it's
> the proper course of action, it's that simple, deal with it.
> It's not that i'm stubborn, i've changed opinion in many occasions, and
> i'm not seeking to "rub it off" - if i wanted to do so i could just say
> "hashes" which i've proposed years ago with the idea being very much
> rejected at the time - i'm not interested in that.

I don't remember if I was pro or against hashes back at the time.
Probably against, since when Yann proposed the patches, I was still a
bit hesitant about this feature.

> It's dissapointing to just sum up commits doing banal stuff even if
> they're important, to then get the cold shoulder when what i feel are
> interesting or progressive ideas get delayed and/or rejected.
> My feeling is that i'm just wasting my time if i make any serious effort
> to improve things, so basically i give up.
> At this point i would have hoped that i've earned some trust with my
> technical choices, but it feels like not.
> That doesn't mean i want a blank check on decisions, don't get that
> interpretation out of it.

You've definitely earned a *lot* of trust, at least to my eyes, and I
believe to many of the other Buildroot developers, Peter included. When
I see a patch from Gustavo doing something on a package, I typically
merge it eyes closed, or only after a quick look at the patch (I never
do any testing of your patches, because I know they basically work).

Beyond this qemu stuff, can you list the patch series/things you've
tried to push and that haven't been accepted? I think it's good to
discuss what caused the frustration.

> In the end it's not the number of commits that count, that's not an
> indication of who's #1, #3 or anything, it may be fun but that's it.
> The momentum is what makes projects great.
> And mine wrt buildroot has been neutralized, i'll just care about my
> little ranch: no autobuild fixing except what i break, no improvements
> except for what i care, no ACKs, no Tested-bys, no #buildroot IRC, no
> opinions and so on.
> Time will tell if i feel like getting back to that or i'll just dial
> down the notch on general involvement permanently (there's a saying
> which i think is quite universal "never say never").
> Sometimes you win sometimes you lose, in both the project and personal
> levels.

Wow, I must say I'm truly shocked that things have reached this level.
This is definitely not where I'd like things to go: your contributions
are very very valuable, and I very often need to refer to you for many
questions/opinions/feedback on various things we're doing in Buildroot.

Would you still be willing to have a Google Hangout at some point this
week to discuss this?

Live discussion very often helps, and it will allow us to exchange our
point of views, and see what we can do to resolve things. At some
point, it would be really great to meet in person, because I believe
you may not realize how much the Buildroot developers value and
respect your contribution.

Best regards,

Thomas
Yann E. MORIN - Oct. 21, 2014, 6:20 p.m.
Gustavo, All,

On 2014-10-21 09:16 +0200, Thomas Petazzoni spake thusly:
> On Mon, 20 Oct 2014 19:45:06 -0300, Gustavo Zacarias wrote:
[--SNIP--]
> > It's dissapointing to just sum up commits doing banal stuff even if
> > they're important, to then get the cold shoulder when what i feel are
> > interesting or progressive ideas get delayed and/or rejected.
> > My feeling is that i'm just wasting my time if i make any serious effort
> > to improve things, so basically i give up.
> > At this point i would have hoped that i've earned some trust with my
> > technical choices, but it feels like not.
> > That doesn't mean i want a blank check on decisions, don't get that
> > interpretation out of it.
> 
> You've definitely earned a *lot* of trust, at least to my eyes, and I
> believe to many of the other Buildroot developers, Peter included.

I agree with Thomas: I too highly recognise your expertise, and that
has earned you my trust, for all the hard topics you have touched in
Buildroot (security, toolchains, weird archs...)

> > In the end it's not the number of commits that count, that's not an
> > indication of who's #1, #3 or anything, it may be fun but that's it.
> > The momentum is what makes projects great.
> > And mine wrt buildroot has been neutralized, i'll just care about my
> > little ranch: no autobuild fixing except what i break, no improvements
> > except for what i care, no ACKs, no Tested-bys, no #buildroot IRC, no
> > opinions and so on.
> > Time will tell if i feel like getting back to that or i'll just dial
> > down the notch on general involvement permanently (there's a saying
> > which i think is quite universal "never say never").
> > Sometimes you win sometimes you lose, in both the project and personal
> > levels.

I am really stunned to read that, and am really sorry you feel like
that. :-(

> Wow, I must say I'm truly shocked that things have reached this level.
> This is definitely not where I'd like things to go: your contributions
> are very very valuable, and I very often need to refer to you for many
> questions/opinions/feedback on various things we're doing in Buildroot.

I can only fully concur to what Thomas said.

> Would you still be willing to have a Google Hangout at some point this
> week to discuss this?

I could try to join, but as I am on the move in the US, it will be a bit
difficult for me. Just arrange for a day and time that suits you, and if
I am able to, I'll join.

Regards,
Yann E. MORIN.
Arnout Vandecappelle - Oct. 21, 2014, 7:45 p.m.
On 21/10/14 09:16, Thomas Petazzoni wrote:
> Dear Gustavo Zacarias,
>
> On Mon, 20 Oct 2014 19:45:06 -0300, Gustavo Zacarias wrote:
>
> >> Yes, it clearly matters. I'm a bit sad to see that this specific story
> >> has affected your motivation. However, on this story, you had your own
> >> idea, and basically rejected the comments that were made. That's not
> >> really the best way to push things forward: maybe doing a concession
> >> sometimes helps, and thanks to this concession, you might prove at a
> >> later point that people were wrong and you were right from the
> >> beginning :)
> >
> > The same can be said the opposite way don't you think?
>
> True in some way. But in another way, doing the concession on what gets
> merged means reducing the "quality" of what we merge. Is this really
> what we want? If something doesn't comply with the Buildroot coding
> style and/or principles, should we merge it just because it has been
> sitting there since one year?

 I wouldn't say it's really a matter of quality. We (or actually, the committers)
tend to be conservative when it comes to merging. In particular, if any controversy
exists over a patch, it just remains sitting in the queue.

 It could be debated whether this is a good thing. But it is the way we work at
the moment.

 But the end result that such controversial patches stay in patchwork for a long
time, nobody comments on them anymore, so the discussion essentially dies. And
then comes along a patchwork cleanup rush, and things get rejected.

 As you mention below w.r.t. the hashes, it's very well possible that a year later
the original idea does suddenly get accepted...


 Regards,
 Arnout

>
> > This patchset has been sitting for almost a year now with no action on
> > the counterproposal from anyone.
> > The likely outcome is that the feature will still be missing until the
> > next release cycle.
>
> I agree this isn't nice. But again, if there is a pending patch that
> doesn't satisfy a majority of developers, should we merge it simply
> because it has been pending for a long time? I'm sure you would agree
> that we should not merge such a patch, even if that means leaving the
> feature out of the tree for a while.
>
> > I won't make a concession on this because i really don't believe it's
> > the proper course of action, it's that simple, deal with it.
> > It's not that i'm stubborn, i've changed opinion in many occasions, and
> > i'm not seeking to "rub it off" - if i wanted to do so i could just say
> > "hashes" which i've proposed years ago with the idea being very much
> > rejected at the time - i'm not interested in that.
>
> I don't remember if I was pro or against hashes back at the time.
> Probably against, since when Yann proposed the patches, I was still a
> bit hesitant about this feature.
>
[snip]
Peter Korsgaard - Oct. 22, 2014, 10:23 a.m.
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

Sorry for slow response - I've been busy with family stuff since I got
home from Dusseldorf. I'm now in the airport leaving for the GSoC
summit.

 >> You've definitely earned a *lot* of trust, at least to my eyes, and I
 >> believe to many of the other Buildroot developers, Peter included.

 > I agree with Thomas: I too highly recognise your expertise, and that
 > has earned you my trust, for all the hard topics you have touched in
 > Buildroot (security, toolchains, weird archs...)

I think we all do. I in general merge Gustavo's patches very fast as
they very rarely have issues.


 >> > Time will tell if i feel like getting back to that or i'll just dial
 >> > down the notch on general involvement permanently (there's a saying
 >> > which i think is quite universal "never say never").
 >> > Sometimes you win sometimes you lose, in both the project and personal
 >> > levels.

 > I am really stunned to read that, and am really sorry you feel like
 > that. :-(

So am I! I must say it comes as quite a shock to me.


 >> Would you still be willing to have a Google Hangout at some point this
 >> week to discuss this?

 > I could try to join, but as I am on the move in the US, it will be a bit
 > difficult for me. Just arrange for a day and time that suits you, and if
 > I am able to, I'll join.

I'm in the same situation as Yann, but I'll join if at all possible.

Patch

diff --git a/package/Config.in.host b/package/Config.in.host
index c6997e9..4faaf60 100644
--- a/package/Config.in.host
+++ b/package/Config.in.host
@@ -13,6 +13,7 @@  source "package/mtools/Config.in.host"
 source "package/omap-u-boot-utils/Config.in.host"
 source "package/openocd/Config.in.host"
 source "package/parted/Config.in.host"
+source "package/qemu-system/Config.in.host"
 source "package/sam-ba/Config.in.host"
 source "package/squashfs/Config.in.host"
 source "package/sunxi-tools/Config.in.host"
diff --git a/package/qemu-system/Config.in.host b/package/qemu-system/Config.in.host
new file mode 100644
index 0000000..b451ca6
--- /dev/null
+++ b/package/qemu-system/Config.in.host
@@ -0,0 +1,30 @@ 
+config BR2_PACKAGE_HOST_QEMU_SYSTEM
+	bool "host qemu-system"
+	# Supported system target architectures
+	depends on BR2_arm || BR2_i386 || BR2_microblaze || BR2_mips \
+		|| BR2_mips64 || BR2_mips64el || BR2_mipsel || BR2_powerpc \
+		|| BR2_sh4 || BR2_sh4eb || BR2_sparc || BR2_x86_64
+	help
+	  QEMU is a generic and open source machine emulator and virtualizer.
+
+	  This option builds a system emulator for your selected architecture.
+
+	  http://www.qemu.org
+
+if BR2_PACKAGE_HOST_QEMU_SYSTEM
+
+config BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION
+	string "qemu version"
+	default "2.0.0"
+	help
+	  QEMU version to use.
+	  Sometimes the latest version is broken for some specific
+	  architecture or target machine.
+
+config BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS
+	string "qemu-system command arguments"
+	help
+	  Arguments to be used for your target host-qemu-system to run
+	  via "make qemu-system-run".
+
+endif
diff --git a/package/qemu-system/qemu-system.mk b/package/qemu-system/qemu-system.mk
new file mode 100644
index 0000000..4a57c8b
--- /dev/null
+++ b/package/qemu-system/qemu-system.mk
@@ -0,0 +1,64 @@ 
+################################################################################
+#
+# qemu-system
+#
+################################################################################
+
+HOST_QEMU_SYSTEM_VERSION = $(call qstrip,$(BR2_PACKAGE_HOST_QEMU_SYSTEM_VERSION))
+HOST_QEMU_SYSTEM_SOURCE = qemu-$(HOST_QEMU_SYSTEM_VERSION).tar.bz2
+QEMU_SYSTEM_SITE = http://wiki.qemu-project.org/download
+QEMU_SYSTEM_LICENSE = GPLv2 LGPLv2.1 MIT BSD-3c BSD-2c Others/BSD-1c
+QEMU_SYSTEM_LICENSE_FILES = COPYING COPYING.LIB
+# NOTE: there is no top-level license file for non-(L)GPL licenses;
+#       the non-(L)GPL license texts are specified in the affected
+#       individual source files.
+
+# host-python required to ensure we use a 2.x series since 3.x isn't supported
+HOST_QEMU_SYSTEM_DEPENDENCIES = host-flex host-bison host-libglib2 \
+	host-pixman host-pkgconf host-python host-zlib
+
+HOST_QEMU_SYSTEM_ARCH = $(ARCH)
+ifeq ($(HOST_QEMU_SYSTEM_ARCH),i486)
+	HOST_QEMU_SYSTEM_ARCH = i386
+endif
+ifeq ($(HOST_QEMU_SYSTEM_ARCH),i586)
+	HOST_QEMU_SYSTEM_ARCH = i386
+endif
+ifeq ($(HOST_QEMU_SYSTEM_ARCH),i686)
+	HOST_QEMU_SYSTEM_ARCH = i386
+endif
+ifeq ($(BR2_microblazeel),y)
+	HOST_QEMU_SYSTEM_ARCH = microblazeel
+endif
+ifeq ($(HOST_QEMU_SYSTEM_ARCH),powerpc)
+	HOST_QEMU_SYSTEM_ARCH = ppc
+endif
+HOST_QEMU_SYSTEM_TARGETS=$(HOST_QEMU_SYSTEM_ARCH)-softmmu
+
+define HOST_QEMU_SYSTEM_CONFIGURE_CMDS
+	(cd $(@D); $(HOST_CONFIGURE_OPTS) ./configure \
+		--target-list="$(HOST_QEMU_SYSTEM_TARGETS)" \
+		--prefix="$(HOST_DIR)/usr" \
+		--cc="$(HOSTCC)" \
+		--host-cc="$(HOSTCC)" \
+		--extra-cflags="$(HOST_CFLAGS)" \
+		--extra-ldflags="$(HOST_LDFLAGS)" \
+		--with-system-pixman \
+	)
+endef
+
+define HOST_QEMU_SYSTEM_BUILD_CMDS
+	$(HOST_MAKE_ENV) $(MAKE) -C $(@D)
+endef
+
+define HOST_QEMU_SYSTEM_INSTALL_CMDS
+	$(HOST_MAKE_ENV) $(MAKE) -C $(@D) install
+endef
+
+$(eval $(host-generic-package))
+
+# System emulation binary used here or somewhere else
+QEMU_SYSTEM = $(HOST_DIR)/usr/bin/qemu-system-$(HOST_QEMU_SYSTEM_ARCH)
+
+qemu-system-run: all
+	$(QEMU_SYSTEM) $(call qstrip,$(BR2_PACKAGE_HOST_QEMU_SYSTEM_ARGS))