kvm:showing a splash picture when start
v2 cover kvm:showing a splash picture when start
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when it
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)
the splash_time is in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.
Patch 1 contains the source modification for qemu-kvm, Patch 2 and
3 are binary patches that added a default logo picture file, alternated the bios.bin to make the sea-bios showing it. Patch 3 is just used to provide a convenient way to test the Patch, waiting for newer version of seabios that provide the support officially.
Any comments would be very nice.
Signature · 5 lines
Best Regards Wayne Xia mail:[email protected] tel:86-010-82450803
Quoted 2 lines · Wayne Xia
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when it
You are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
Quoted 3 lines
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)
Simply 'splash' for specifying the file should suffice.
Quoted 2 lines
the
splash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.
Strong NAK for making this default. We have a nice sub-second BIOS time in QEMU, and that must not be destroyed by eye candy. 5 s is also way too long even when you want splash.
Quoted 6 lines
Patch 1 contains the source modification for qemu-kvm, Patch 2 and
3 are binary patches that added a default logo picture file, alternated the bios.bin to make the sea-bios showing it. Patch 3 is just used to provide a convenient way to test the Patch, waiting for newer version of seabios that provide the support officially.
Any comments would be very nice.
- commit logs a missing in the individual patches
- the BIOS is updated via submodule reference, and that only to SeaBIOS releases (IOW,
you can only provide a test image so far, no patch)
- a default logo should not mention KVM but QEMU (splash is not limited to KVM mode)
Jan
2011/6/23 Jan Kiszka <[email protected]>:
Quoted 6 lines · Wayne Xia
Quoted 2 lines
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when itYou are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
More specifically, develop code against qemu.git as a default. Much
of the development that goes into qemu-kvm actually comes via qemu.git. If you need to do qemu-kvm.git specific stuff, you'll know.
Additional info:
"The QEMU codebase is known as qemu.git. That's the git repository that holds the QEMU source code history. The KVM codebase is known as qemu-kvm.git, the git repository that holds the KVM source code history.
The relationship between qemu.git and qemu-kvm.git is as follows. qemu-kvm.git is a fork of qemu.git and periodically merges updates from qemu.git back into qemu-kvm.git. A lot of code changes are merged into qemu.git and become available in qemu-kvm.git after the next periodic merge. KVM-specific enhancements may be merged into qemu-kvm.git and may be sent back upstream to qemu.git.
Efforts are underway to completely merge qemu-kvm.git into qemu.git. This will make qemu-kvm.git obsolete and result in a single codebase. In the future there may only be a qemu package."
http://blog.vmsplice.net/2011/03/should-i-use-qemu-or-kvm.html
Stefan
Quoted 25 lines · Stefan Hajnoczi
2011/6/23 Jan Kiszka <[email protected]>:
Quoted 6 lines · Wayne Xia
Quoted 2 lines
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when itYou are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
More specifically, develop code against qemu.git as a default. Much
of the development that goes into qemu-kvm actually comes via qemu.git. If you need to do qemu-kvm.git specific stuff, you'll know.Additional info:
"The QEMU codebase is known as qemu.git. That's the git repository that holds the QEMU source code history. The KVM codebase is known as qemu-kvm.git, the git repository that holds the KVM source code history.The relationship between qemu.git and qemu-kvm.git is as follows. qemu-kvm.git is a fork of qemu.git and periodically merges updates from qemu.git back into qemu-kvm.git. A lot of code changes are merged into qemu.git and become available in qemu-kvm.git after the next periodic merge. KVM-specific enhancements may be merged into qemu-kvm.git and may be sent back upstream to qemu.git.
Quoted 5 lines
Efforts are underway to completely merge qemu-kvm.git into qemu.git. This will make qemu-kvm.git obsolete and result in a single codebase. In the future there may only be a qemu package."
http://blog.vmsplice.net/2011/03/should-i-use-qemu-or-kvm.html
BTW, do we have such information in the linux-kvm.org and maybe also qemu.org wikis? If not, I guess it would help, in some cases at least.
Jan
Quoted 26 lines · Jan Kiszka
Quoted 25 lines · Stefan Hajnoczi
2011/6/23 Jan Kiszka <[email protected]>:
Quoted 6 lines · Wayne Xia
Quoted 2 lines
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when itYou are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
More specifically, develop code against qemu.git as a default. Much of the development that goes into qemu-kvm actually comes via qemu.git. If you need to do qemu-kvm.git specific stuff, you'll know.
Additional info:
"The QEMU codebase is known as qemu.git. That's the git repository that holds the QEMU source code history. The KVM codebase is known as qemu-kvm.git, the git repository that holds the KVM source code history.The relationship between qemu.git and qemu-kvm.git is as follows. qemu-kvm.git is a fork of qemu.git and periodically merges updates from qemu.git back into qemu-kvm.git. A lot of code changes are merged into qemu.git and become available in qemu-kvm.git after the next periodic merge. KVM-specific enhancements may be merged into qemu-kvm.git and may be sent back upstream to qemu.git.
Quoted 8 lines
Quoted 5 lines
Efforts are underway to completely merge qemu-kvm.git into qemu.git. This will make qemu-kvm.git obsolete and result in a single codebase. In the future there may only be a qemu package."
http://blog.vmsplice.net/2011/03/should-i-use-qemu-or-kvm.html
BTW, do we have such information in the linux-kvm.org and maybe also qemu.org wikis? If not, I guess it would help, in some cases at least.
I have added the following:
"If you want to contribute code, please develop against qemu.git and submit patches to [email protected]. The qemu-kvm.git tree regularly gets changes from qemu.git and patches against qemu-kvm.git should be minimized."
http://www.linux-kvm.org/page/Code
Avi and Marcelo: hope you are okay with this wiki change, please revert or reword if you feel the wording should be improved.
Stefan
Quoted 6 lines · Stefan Hajnoczi
Quoted 3 lines
BTW, do we have such information in the linux-kvm.org and maybe also qemu.org wikis? If not, I guess it would help, in some cases at least.
I have added the following:
Quoted 8 lines
"If you want to contribute code, please develop against qemu.git and submit patches to [email protected]. The qemu-kvm.git tree regularly gets changes from qemu.git and patches against qemu-kvm.git should be minimized."
http://www.linux-kvm.org/page/CodeAvi and Marcelo: hope you are okay with this wiki change, please revert or reword if you feel the wording should be improved.
Looks good, thanks.
Signature · 1 line
error compiling committee.c: too many arguments to function
I guess that Wayne should target qemu-kvm git tree.
Regards,
Zhiyong Wu
Quoted 34 lines · Stefan Hajnoczi
2011/6/23 Jan Kiszka <[email protected]>:
Quoted 6 lines · Wayne Xia
Quoted 2 lines
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when itYou are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
More specifically, develop code against qemu.git as a default. Much of the development that goes into qemu-kvm actually comes via qemu.git. If you need to do qemu-kvm.git specific stuff, you'll know.
Additional info:
"The QEMU codebase is known as qemu.git. That's the git repository that holds the QEMU source code history. The KVM codebase is known as qemu-kvm.git, the git repository that holds the KVM source code history.The relationship between qemu.git and qemu-kvm.git is as follows. qemu-kvm.git is a fork of qemu.git and periodically merges updates from qemu.git back into qemu-kvm.git. A lot of code changes are merged into qemu.git and become available in qemu-kvm.git after the next periodic merge. KVM-specific enhancements may be merged into qemu-kvm.git and may be sent back upstream to qemu.git.
Efforts are underway to completely merge qemu-kvm.git into qemu.git. This will make qemu-kvm.git obsolete and result in a single codebase. In the future there may only be a qemu package."
http://blog.vmsplice.net/2011/03/should-i-use-qemu-or-kvm.html
Stefan
Signature · 3 lines
Regards, Zhi Yong Wu
Quoted 1 line · Zhi Yong Wu
I guess that Wayne should target qemu-kvm git tree.
Nope, qemu.git is correct.
Jan
Jan,
Sorry, i just made a mistake, and thanks.
Quoted 8 lines · Jan Kiszka
Quoted 1 line · Zhi Yong Wu
I guess that Wayne should target qemu-kvm git tree.
Nope, qemu.git is correct.
Jan
Signature · 3 lines
Regards, Zhi Yong Wu
2011-6-23 18:03, Jan Kiszka
Quoted 7 lines · Wayne Xia
Quoted 2 lines
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when itYou are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
thanks for the tip.
Quoted 4 lines
Quoted 3 lines
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)
Quoted 9 lines
Simply 'splash' for specifying the file should suffice.
Quoted 2 lines
the
splash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.Strong NAK for making this default. We have a nice sub-second BIOS time in QEMU, and that must not be destroyed by eye candy. 5 s is also way too long even when you want splash.
Maybe 5 is a bit too long, this patch is for test so made it a bit longer to be observed by VNC, I think 2.5s would be fit.
Quoted 8 lines
Quoted 6 lines
Patch 1 contains the source modification for qemu-kvm, Patch 2 and
3 are binary patches that added a default logo picture file, alternated the bios.bin to make the sea-bios showing it. Patch 3 is just used to provide a convenient way to test the Patch, waiting for newer version of seabios that provide the support officially.
Any comments would be very nice.- commit logs a missing in the individual patches
I think patch 3/3 may be in the junk mail box.
Quoted 5 lines
- the BIOS is updated via submodule reference, and that only to SeaBIOS releases (IOW,
you can only provide a test image so far, no patch)
- a default logo should not mention KVM but QEMU (splash is not limited to KVM mode)
we can switch it for a more official picture for different release.
Quoted 2 lines
Jan
Signature · 5 lines
Best Regards Wayne Xia mail:[email protected] tel:86-010-82450803
Quoted 18 lines · Wayne Xia
2011-6-23 18:03, Jan Kiszka
Quoted 7 lines · Wayne Xia
Quoted 2 lines
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when itYou are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
thanks for the tip.
Quoted 9 lines
Quoted 3 lines
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)Simply 'splash' for specifying the file should suffice.
Quoted 2 lines
the
splash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.
Quoted 6 lines
Quoted 4 lines
Strong NAK for making this default. We have a nice sub-second BIOS time in QEMU, and that must not be destroyed by eye candy. 5 s is also way too long even when you want splash.
Maybe 5 is a bit too long, this patch is for test so made it a bit longer to be observed by VNC, I think 2.5s would be fit.
Maybe it could be something like that if the user specifies a splash file - which indicates that there should be some splash delay as well. Default without any splash parameter must remain 0, ie. disabled.
Jan
Quoted 23 lines · Jan Kiszka
Quoted 22 lines · Wayne Xia
2011-6-23 18:03, Jan Kiszka
Quoted 7 lines · Wayne Xia
Quoted 2 lines
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when itYou are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
thanks for the tip.
Quoted 13 lines
Quoted 3 lines
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)Simply 'splash' for specifying the file should suffice.
Quoted 2 lines
the
splash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.Strong NAK for making this default. We have a nice sub-second BIOS time in QEMU, and that must not be destroyed by eye candy. 5 s is also way too long even when you want splash.
Quoted 6 lines
Quoted 2 lines
Maybe 5 is a bit too long, this patch is for test so made it a bit longer to be observed by VNC, I think 2.5s would be fit.
Maybe it could be something like that if the user specifies a splash file - which indicates that there should be some splash delay as well. Default without any splash parameter must remain 0, ie. disabled.
I don't think you want to change default timeouts based on whether a splash screen is present. Consider that if you have enabled PXE boot on one of the guest NICs, then there is already a few second delay while the BIOS PXEs, during which it QEMU would be showing the splash screen. You don't then want to add a further 2.5s or 5s delay ontop of that already imposed by the BIOS PXE process. Just let the splash screen be displayed for however long the BIOS process takes, without any extra artifical delays, even if this is a mere fraction of a second in some cases.
Daniel
Signature · 4 lines
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Quoted 31 lines · Daniel P. Berrange
Quoted 23 lines · Jan Kiszka
Quoted 22 lines · Wayne Xia
2011-6-23 18:03, Jan Kiszka
Quoted 7 lines · Wayne Xia
Quoted 2 lines
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when itYou are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
thanks for the tip.
Quoted 13 lines
Quoted 3 lines
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)Simply 'splash' for specifying the file should suffice.
Quoted 2 lines
the
splash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.Strong NAK for making this default. We have a nice sub-second BIOS time in QEMU, and that must not be destroyed by eye candy. 5 s is also way too long even when you want splash.
Quoted 6 lines
Quoted 2 lines
Maybe 5 is a bit too long, this patch is for test so made it a bit longer to be observed by VNC, I think 2.5s would be fit.
Maybe it could be something like that if the user specifies a splash file - which indicates that there should be some splash delay as well. Default without any splash parameter must remain 0, ie. disabled.
Quoted 9 lines
I don't think you want to change default timeouts based on whether a splash screen is present. Consider that if you have enabled PXE boot on one of the guest NICs, then there is already a few second delay while the BIOS PXEs, during which it QEMU would be showing the splash screen. You don't then want to add a further 2.5s or 5s delay ontop of that already imposed by the BIOS PXE process. Just let the splash screen be displayed for however long the BIOS process takes, without any extra artifical delays, even if this is a mere fraction of a second in some cases.
I don't want the splash to show up at all by default, even just for a fraction of a second. Already loading that image costs time (specifically as it's squeezed into fwcfg), and that would be unacceptable.
My point is that, if the user specifies "-boot splash=my-nice-splace.bmp", there is likely the wish to see the result more than a few 100 ms. Again, that's the case where the user asked for a slowdown anyway.
Jan
Am 23.06.2011 um 14:29 schrieb Jan Kiszka:
Quoted 34 lines · Daniel P. Berrange
Quoted 23 lines · Jan Kiszka
Quoted 15 lines · Wayne Xia
Quoted 14 lines
2011-6-23 18:03, Jan Kiszka
Quoted 13 lines · Wayne Xia
Quoted 1 line
-boot (splash_time=<N>,) (splash_filename=<N>,)Simply 'splash' for specifying the file should suffice.
Quoted 3 lines
the
splash_timeis in the unit of ms, and its max value is
65535.
this feature is by default on with 5000ms showing up.Strong NAK for making this default. We have a nice sub-second BIOS time in QEMU, and that must not be destroyed by eye candy. 5 s is also way too long even when you want splash.
Quoted 6 lines
Quoted 2 lines
Maybe 5 is a bit too long, this patch is for test so made it a bit longer to be observed by VNC, I think 2.5s would be fit.
Maybe it could be something like that if the user specifies a splash file - which indicates that there should be some splash delay as well. Default without any splash parameter must remain 0, ie. disabled.
Quoted 9 lines
I don't think you want to change default timeouts based on whether a splash screen is present. Consider that if you have enabled PXE boot on one of the guest NICs, then there is already a few second delay while the BIOS PXEs, during which it QEMU would be showing the splash screen. You don't then want to add a further 2.5s or 5s delay ontop of that already imposed by the BIOS PXE process. Just let the splash screen be displayed for however long the BIOS process takes, without any extra artifical delays, even if this is a mere fraction of a second in some cases.
Quoted 8 lines
I don't want the splash to show up at all by default, even just for a fraction of a second. Already loading that image costs time (specifically as it's squeezed into fwcfg), and that would be unacceptable.
My point is that, if the user specifies "-boot splash=my-nice-splace.bmp", there is likely the wish to see the result more than a few 100 ms. Again, that's the case where the user asked for a slowdown anyway.
Déjà-entendu... Wasn't there something about a delay for key presses that was removed and the menu=on parameter added for that? Can't we just tie the bootsplash to existing menu=on and be good?
Andreas
2011-6-23 20:29, Jan Kiszka :
Quoted 42 lines · Daniel P. Berrange
Quoted 31 lines · Jan Kiszka
Quoted 23 lines · Wayne Xia
Quoted 22 lines
2011-6-23 18:03, Jan Kiszka
Quoted 7 lines · Wayne Xia
Quoted 2 lines
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when itYou are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
thanks for the tip.
Quoted 13 lines
Quoted 3 lines
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)Simply 'splash' for specifying the file should suffice.
Quoted 2 lines
the
splash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.Strong NAK for making this default. We have a nice sub-second BIOS time in QEMU, and that must not be destroyed by eye candy. 5 s is also way too long even when you want splash.
Quoted 6 lines
Quoted 2 lines
Maybe 5 is a bit too long, this patch is for test so made it a bit longer to be observed by VNC, I think 2.5s would be fit.
Maybe it could be something like that if the user specifies a splash file - which indicates that there should be some splash delay as well. Default without any splash parameter must remain 0, ie. disabled.
Quoted 9 lines
I don't think you want to change default timeouts based on whether a splash screen is present. Consider that if you have enabled PXE boot on one of the guest NICs, then there is already a few second delay while the BIOS PXEs, during which it QEMU would be showing the splash screen. You don't then want to add a further 2.5s or 5s delay ontop of that already imposed by the BIOS PXE process. Just let the splash screen be displayed for however long the BIOS process takes, without any extra artifical delays, even if this is a mere fraction of a second in some cases.
Quoted 9 lines
I don't want the splash to show up at all by default, even just for a fraction of a second. Already loading that image costs time (specifically as it's squeezed into fwcfg), and that would be unacceptable.
My point is that, if the user specifies "-boot splash=my-nice-splace.bmp", there is likely the wish to see the result more than a few 100 ms. Again, that's the case where the user asked for a slowdown anyway.
Completely understand that in most cases the Qemu-kvm should boot up
as soon as it can. Making this default now is just to provide a convenient way to test it temporarily, I did that to make it easily tested in the GUI--Virtual Machine Manager which would not accept additional parameters to enable the splash screen. Sorry for having not explained it clearly.
I agree that if the user specifies it, then this logo would be
shown.
Quoted 2 lines
Jan
Signature · 5 lines
Best Regards Wayne Xia mail:[email protected] tel:86-010-82450803
Quoted 18 lines · Wayne Xia
2011-6-23 18:03, Jan Kiszka
Quoted 7 lines · Wayne Xia
Quoted 2 lines
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when itYou are posting on qemu-devel (which is correct for this topic), so your patches must target that tree. Patch 1 eg. does not and needs rebasing.
thanks for the tip.
Quoted 9 lines
Quoted 3 lines
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)Simply 'splash' for specifying the file should suffice.
Quoted 2 lines
the
splash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.
Quoted 6 lines
Quoted 4 lines
Strong NAK for making this default. We have a nice sub-second BIOS time in QEMU, and that must not be destroyed by eye candy. 5 s is also way too long even when you want splash.
Maybe 5 is a bit too long, this patch is for test so made it a bit longer to be observed by VNC, I think 2.5s would be fit.
A splash screen provides no useful information to the end user, so they won't care about seeing it in VNC or anyother display protocol. All that matters is to get users to their working OS as fast as possible. So 0s, aka no splash screen, should be the default.
Daniel
Signature · 4 lines
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Quoted 7 lines · Wayne Xia
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when it
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)
thesplash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.
Real machines have splash screens because they take soo long to initialize. KVM guests go almost instantly to the guest OS, which is a clear step forward. Adding in a 5000ms delay to KVM guests is just a huge, pointless step back again.
Regards,
Daniel
Signature · 4 lines
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Quoted 5 lines · Wayne Xia
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when it
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)
Quoted 8 lines
the
splash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.
Patch 1 contains the source modification for qemu-kvm, Patch 2 and
3 are binary patches that added a default logo picture file, alternated the bios.bin to make the sea-bios showing it. Patch 3 is just used to provide a convenient way to test the Patch, waiting for newer version of seabios that provide the support officially.
Any comments would be very nice.
Splash screens are a terrible idea. We should work instead on making the boot even faster.
And having it *default* to 5 seconds! That's like, nearly double the time it takes to launch libguestfs completely!!
Please don't accept these patches.
Rich.
Signature · 4 lines
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
Quoted 15 lines · Richard W.M. Jones
Quoted 5 lines · Wayne Xia
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when it
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)Quoted 8 lines
the
splash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.
Patch 1 contains the source modification for qemu-kvm, Patch 2 and
3 are binary patches that added a default logo picture file, alternated the bios.bin to make the sea-bios showing it. Patch 3 is just used to provide a convenient way to test the Patch, waiting for newer version of seabios that provide the support officially.
Any comments would be very nice.
Quoted 2 lines
Splash screens are a terrible idea. We should work instead on making the boot even faster.
I completely agree. Qemu does not do much in the BIOS (as a regular PC does while initializing various devices, reading boot records and so on), so there's nothing to hide here (except of problem reports in case of trouble - it's already waaay more than enough when people use -daemonize option which effectively turns off stderr).
While booting the system it's possible to have its own splash screen if desirable.
But the whole thing is somewhat moot for qemu anyway:
just start whole thing in background.
Quoted 1 line
Please don't accept these patches.
*nod*
/mjt
Quoted 15 lines · Richard W.M. Jones
Quoted 5 lines · Wayne Xia
Hi,
these 3 patch simply enable qemu-kvm to show a logo picture when it
s start up, following is how to configurate it:
invoke it with params:
-boot (splash_time=<N>,) (splash_filename=<N>,)Quoted 8 lines
the
splash_timeis in the unit of ms, and its max value is 65535.
this feature is by default on with 5000ms showing up.
Patch 1 contains the source modification for qemu-kvm, Patch 2 and
3 are binary patches that added a default logo picture file, alternated the bios.bin to make the sea-bios showing it. Patch 3 is just used to provide a convenient way to test the Patch, waiting for newer version of seabios that provide the support officially.
Any comments would be very nice.
Quoted 1 line
Splash screens are a terrible idea.
No, they're not.
Quoted 1 line
We should work instead on making the boot even faster.
Having the ability to have an optional splash screen does not slow down boot for the cases when it's not enabled. It's extremely valuable in many use-cases to enable branding.
Quoted 2 lines
And having it *default* to 5 seconds! That's like, nearly double the time it takes to launch libguestfs completely!!
No one is saying that libguestfs has to enable a splash screen during it's guest start up.
Regards,
Anthony Liguori
Quoted 4 lines
Please don't accept these patches.
Rich.