| Message ID | 1399148415-27648-1-git-send-email-gustavo@zacarias.com.ar |
|---|---|
| State | Changes Requested |
| Headers | show |
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
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.
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 > >
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.
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.
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.
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
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
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.
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
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
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.
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
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.
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]
>>>>> "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.
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))
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