From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fb43b-0003eb-L3 for qemu-devel@nongnu.org; Thu, 05 Jul 2018 09:12:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fb43X-0006EH-KN for qemu-devel@nongnu.org; Thu, 05 Jul 2018 09:12:23 -0400 Date: Thu, 5 Jul 2018 10:12:11 -0300 From: Eduardo Habkost Message-ID: <20180705131211.GJ7451@localhost.localdomain> References: <20180704112859.20146-1-kraxel@redhat.com> <20180704185321.GZ7451@localhost.localdomain> <6a0aba7b46b168360fb291eaec769eb0@sebastianbauer.info> <20180704205206.GG7451@localhost.localdomain> <20180704210459.GH7451@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] vga: make stdvga the global default List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sebastian Bauer Cc: Gerd Hoffmann , qemu-devel@nongnu.org, Paolo Bonzini , Alexander Graf , Marcel Apfelbaum , Aleksandar Markovic , Aurelien Jarno , "Michael S. Tsirkin" , David Gibson , BALATON Zoltan , qemu-ppc@nongnu.org, Richard Henderson On Thu, Jul 05, 2018 at 05:43:45AM +0200, Sebastian Bauer wrote: > Am 2018-07-04 23:04, schrieb Eduardo Habkost: > > On Wed, Jul 04, 2018 at 05:52:06PM -0300, Eduardo Habkost wrote: > > > On Wed, Jul 04, 2018 at 10:21:19PM +0200, Sebastian Bauer wrote: > > > > Am 2018-07-04 20:53, schrieb Eduardo Habkost: > > > > > > mc->kvm_type = spapr_kvm_type; > > > > > > machine_class_allow_dynamic_sysbus_dev(mc, > > > > > > TYPE_SPAPR_PCI_HOST_BRIDGE); > > > > > > mc->pci_allow_0_address = true; > > > > > > diff --git a/vl.c b/vl.c > > > > > > index 16b913f9d5..e60bf2d6cd 100644 > > > > > > --- a/vl.c > > > > > > +++ b/vl.c > > > > > > @@ -4475,10 +4475,10 @@ int main(int argc, char **argv, char **envp) > > > > > > if (default_vga) { > > > > > > if (machine_class->default_display) { > > > > > > vga_model = machine_class->default_display; > > > > > > - } else if (vga_interface_available(VGA_CIRRUS)) { > > > > > > - vga_model = "cirrus"; > > > > > > } else if (vga_interface_available(VGA_STD)) { > > > > > > vga_model = "std"; > > > > > > + } else if (vga_interface_available(VGA_CIRRUS)) { > > > > > > + vga_model = "cirrus"; > > > > > > > > > > If we don't make the machines above have default_display=NULL, we > > > > > won't need this hunk, right? In either case, I suggest doing > > > > > this change on a separate patch. > > > > > > > > An alternative would be to define the default always to VGA_STD if the > > > > machine does not override it. This is from the observation that the majority > > > > would chose std. Obviously, having default values always has pro and cons. I > > > > would not consider it harmful here. > > > > > > That would be my preference: not having any machine with > > > default_display==NULL. I just don't want to make this a > > > requirement for fixing the current bug. > > > > > > > > > > > Is there any configuration that includes VGA_CIRRUS but not VGA_STD? > > > > > > Not sure, I'll check. > > > > I couldn't find any: > > Thanks for checking! In that case, the VGA_CIRRUS branch in the above hunk > will never be executed (for any current config) after the proposed patch. So > that branch could be eliminated. I'd prefer to eliminate both vga_interface_available() checks. > > I also checked the code, default values are used also for other fields in > that struct (e.g., default_cpus). If default values are considered fragile, > they must be changed as well in the middle term. However, given a solid > documentation (which is currently missing for these fields) I still think > that default values are acceptable. > > Note that there seems also be the possibility to set != NULL default values > in the machine_class_init() function. I don't mind if the default value is defined at machine_class_init() or main(). What bothers me is a default value that depends on vga_interface_available(), because it can be easily broken by a build config change (as demonstrated by the bug fixed by this patch). -- Eduardo