From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L0iDc-0006q3-Ee for qemu-devel@nongnu.org; Thu, 13 Nov 2008 14:51:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L0iDa-0006ov-4U for qemu-devel@nongnu.org; Thu, 13 Nov 2008 14:51:07 -0500 Received: from [199.232.76.173] (port=60517 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0iDZ-0006oh-ND for qemu-devel@nongnu.org; Thu, 13 Nov 2008 14:51:05 -0500 Received: from ik-out-1112.google.com ([66.249.90.180]:32989) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L0iDX-0008VQ-QY for qemu-devel@nongnu.org; Thu, 13 Nov 2008 14:51:05 -0500 Received: by ik-out-1112.google.com with SMTP id b32so980940ika.2 for ; Thu, 13 Nov 2008 11:51:01 -0800 (PST) Message-ID: <491C8520.5040005@codemonkey.ws> Date: Thu, 13 Nov 2008 13:50:56 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <> <1226594763-2304-1-git-send-email-markmc@redhat.com> <1226594763-2304-2-git-send-email-markmc@redhat.com> <1226594763-2304-3-git-send-email-markmc@redhat.com> <1226594763-2304-4-git-send-email-markmc@redhat.com> <1226594763-2304-5-git-send-email-markmc@redhat.com> <1226594763-2304-6-git-send-email-markmc@redhat.com> In-Reply-To: <1226594763-2304-6-git-send-email-markmc@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 5/5] monitor: add "info capabilities" command Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin Cc: qemu-devel@nongnu.org Mark McLoughlin wrote: > +static void do_info_capabilities(void) > +{ > + term_printf("[qemu]\n"); > + list_printf("accel", accel_names); > + term_printf("arch=%s\n", TARGET_ARCH); > + list_printf("cpu", cpu_names()); > + machines_printf(); > + > + term_printf("\n"); > + > + do_machine_capabilities(); > + > + term_printf("[devices]\n"); > + list_printf("bluetooth", bt_list_types()); > + list_printf("char", qemu_chr_list_types()); > + list_printf("drive_cache", drive_cache_types()); > + list_printf("drive_if", drive_if_types()); > + list_printf("graphics", graphics_list_types()); > + list_printf("network", net_client_types()); > +#ifdef HAS_AUDIO > + list_printf("soundhw", soundhw_list_types()); > +#endif > + list_printf("vga", vga_list_types()); > + > + term_printf("\n"); > This makes me uneasy because it introduces a lot of dependencies that are going to be hard to break. I think this level of logic needs to be more encapsulated in the various subsystems. > + > + term_printf("[limits]\n"); > + term_printf("max_boot_dev=q\n"); /* above '-boot q' not allowed */ > + term_printf("max_bluetooth_devs=%d\n", MAX_BT_CMDLINE); > + term_printf("max_drives=%d\n", MAX_DRIVES); > + term_printf("max_ide_devs=%d\n", MAX_IDE_DEVS); > + term_printf("max_net_clients=%d\n", MAX_NET_CLIENTS); > + term_printf("max_nics=%d\n", MAX_NICS); > + term_printf("max_option_roms=%d\n", MAX_OPTION_ROMS); > + term_printf("max_parallel_ports=%d\n", MAX_PARALLEL_PORTS); > +#ifdef TARGET_SPARC > + term_printf("max_prom_envs=%d\n", MAX_PROM_ENVS); > +#endif > + term_printf("max_scsi_devs=%d\n", MAX_SCSI_DEVS); > + term_printf("max_serial_ports=%d\n", MAX_SERIAL_PORTS); > + term_printf("max_usb_devs=%d\n", MAX_USB_CMDLINE); > While we have a lot of hard coded maximums today, I don't think we always will. How do you intend to support an unlimited number of things? Regards, Anthony Liguori