And also do some code cleanup.
A lot of thanks to Markus's review and advice.

Li Qiang (3):
  fw_cfg: fix -boot bootsplash error checking
  fw_cfg: fix -boot reboot-timeout error checking
  fw_cfg: make qemu_extra_params_fw locally

 hw/nvram/fw_cfg.c       | 68 ++++++++++++++++++-----------------------
 include/sysemu/sysemu.h |  1 -
 vl.c                    |  4 +--
 3 files changed, 32 insertions(+), 41 deletions(-)

-- 
2.17.1

Li Qiang <liq3ea@163.com> writes:

> And also do some code cleanup.
> A lot of thanks to Markus's review and advice.
>
> Li Qiang (3):
>   fw_cfg: fix -boot bootsplash error checking
>   fw_cfg: fix -boot reboot-timeout error checking
>   fw_cfg: make qemu_extra_params_fw locally
>
>  hw/nvram/fw_cfg.c       | 68 ++++++++++++++++++-----------------------
>  include/sysemu/sysemu.h |  1 -
>  vl.c                    |  4 +--
>  3 files changed, 32 insertions(+), 41 deletions(-)

fw_cfg.c has no maintainer.  Who would be willing to merge this?

Hi Markus, Li.

On 20/11/18 20:34, Markus Armbruster wrote:
> Li Qiang <liq3ea@163.com> writes:
> 
>> And also do some code cleanup.
>> A lot of thanks to Markus's review and advice.
>>
>> Li Qiang (3):
>>    fw_cfg: fix -boot bootsplash error checking
>>    fw_cfg: fix -boot reboot-timeout error checking
>>    fw_cfg: make qemu_extra_params_fw locally
>>
>>   hw/nvram/fw_cfg.c       | 68 ++++++++++++++++++-----------------------
>>   include/sysemu/sysemu.h |  1 -
>>   vl.c                    |  4 +--
>>   3 files changed, 32 insertions(+), 41 deletions(-)
> 
> fw_cfg.c has no maintainer.  Who would be willing to merge this?

I have various patches for fw_cfg waiting 4.0 to start, one add a 
MAINTAINERS entry covered by Laszlo, Gerd and myself.

This series was published way before soft freeze, but I am not sure it 
applies for hard freeze. If so, it might goes thru Paolo's Misc tree, 
else we'll take it for 4.0 (via fw_cfg-next).

Regards,

Phil.

At 2018-11-21 03:59:28, "Philippe Mathieu-Daudé" <philmd@redhat.com> wrote:
>Hi Markus, Li.
>
>On 20/11/18 20:34, Markus Armbruster wrote:
>> Li Qiang <liq3ea@163.com> writes:
>> 
>>> And also do some code cleanup.
>>> A lot of thanks to Markus's review and advice.
>>>
>>> Li Qiang (3):
>>>    fw_cfg: fix -boot bootsplash error checking
>>>    fw_cfg: fix -boot reboot-timeout error checking
>>>    fw_cfg: make qemu_extra_params_fw locally
>>>
>>>   hw/nvram/fw_cfg.c       | 68 ++++++++++++++++++-----------------------
>>>   include/sysemu/sysemu.h |  1 -
>>>   vl.c                    |  4 +--
>>>   3 files changed, 32 insertions(+), 41 deletions(-)
>> 
>> fw_cfg.c has no maintainer.  Who would be willing to merge this?
>
>I have various patches for fw_cfg waiting 4.0 to start, one add a 
>MAINTAINERS entry covered by Laszlo, Gerd and myself.

>


Nice, when 4.0 window open? I don't find the release planning.
Maybe my another fw_cfg patches can be merged:
-->https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00004.html
-->https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00005.html


Also I've prepared some qtest patch for fw_cfg. 


PS: I'm quite surprise the qemu's version up to 4 quickly(anyway, the 3.1 is just begin)...


Thanks,
Li Qiang


>This series was published way before soft freeze, but I am not sure it 
>applies for hard freeze. If so, it might goes thru Paolo's Misc tree, 

>else we'll take it for 4.0 (via fw_cfg-next).


>
>Regards,
>
>Phil.

On 11/20/18 9:31 PM, 李强 wrote:

> 
> Nice, when 4.0 window open? I don't find the release planning.

https://wiki.qemu.org/Planning gives the overview, and 
https://wiki.qemu.org/Planning/3.1 gives the dates we are trying to hit 
for 3.1.

> Maybe my another fw_cfg patches can be merged:
> -->https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00004.html
> -->https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00005.html

Any new features have missed 3.1, especially since -rc2 has already been 
cut.  There is still room for bug fixes in -rc3, but the bar gets 
progressively higher (we are reluctant to take something that might 
destabilize the binaries without adequate time for testing), and while 
we want to avoid an -rc4, past history says we'll probably have one, 
although it will be as limited as possible.

> PS: I'm quite surprise the qemu's version up to 4 quickly(anyway, the 3.1 is just begin)...

Version numbers are somewhat arbitrary.  We recently switched to bumping 
the major version every year (it's arbitrary, after all), so 2019 will 
have 4.0, 4.1, and probably 4.2 (if we stick to a release every 4 
months) before 2020 starting with 5.0.  The change from 3.0 to 3.1 will, 
in reality, be about the same as the change from 3.1 to 4.0.  A better 
way to think of it is that both the old and new naming schemes are both 
arbitrary, but the new naming scheme has the benefit of not resulting in 
large minor numbers.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org