From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0t3S-0006ji-Go for qemu-devel@nongnu.org; Sun, 21 Jul 2013 08:48:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0t3P-0004J0-OX for qemu-devel@nongnu.org; Sun, 21 Jul 2013 08:48:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0t3P-0004Iu-EB for qemu-devel@nongnu.org; Sun, 21 Jul 2013 08:47:59 -0400 Date: Sun, 21 Jul 2013 15:49:19 +0300 From: "Michael S. Tsirkin" Message-ID: <20130721124919.GA11438@redhat.com> References: <1374136063-24399-1-git-send-email-marcel.a@redhat.com> <51EBCF70.3070303@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <51EBCF70.3070303@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH 0/2] qemu-help: improve -device command line help List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: pbonzini@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, Marcel Apfelbaum On Sun, Jul 21, 2013 at 02:09:20PM +0200, Andreas F=E4rber wrote: > Hi, >=20 > Am 18.07.2013 10:27, schrieb Marcel Apfelbaum: > > Running qemu with "-device ?" option returns ~145 lines. > > It is hard to manage understanding the output. > >=20 > > Theses patches aim to partially solve the problem by dividing the dev= ices > > into logical categories like "Network/Display/..." and sorting them b= y it. > >=20 > > Marcel Apfelbaum (2): > > qemu-help: Sort devices by logical functionality > > devices: Associate devices to their logical category >=20 > Sorry to jump on this discussion. I think the idea to structure devices > better does make sense. However I feel that the implementation is not i= deal: >=20 > For one, this adds a new field and uses it only for command line output= , > while not benefiting libvirt or other QMP users. This is not a problem with implementation - that can be added on top. I think HMP is a good start, that's where we have a real pain point now, with basically no documentation, and it's a less risky change with no compatibility commitments. > For another, this adds a third tree overlay over devices: Exactly. And that's by design since this information is currently missing. > We have the QOM inheritance tree with classifications such as PCIDevice= , > ISADevice, VirtioDevice, USBDevice, etc. > > We have Paolo's hw/ directory restructuring, which uses scsi, intc, > timer, etc. sub-directories. > > The proposed category system is different from the sub-directories > (e.g., scsi/ vs STORAGE) and is completely manual, i.e. double work. > > So I wonder if it would be possible to define the category per > Makefile.objs (whether in hw/Makefile.objs or in hw/*/Makefile.objs). This idea can't support multi-category devices. To me, duplication seems minimal. On the other hand plain C is much more readable than makefile based trick= s. > Or whether we can just reuse the type hierarchy and sort per base class > for now - the result would be different from the proposed categories bu= t > hopefully reproducible elsewhere (assuming the base type is exposed in > QMP). What you suggest is mostly already available in the form of "bus" field in -device help output. But this misses the whole point which is to help users find devices implementing a specific functionality. > Anthony had in the past suggested to change our inheritance tree > so that PCIDevice becomes an interface and the base class would be > specific to the chipset, i.e. might end up similar to the proposed > categories. (Getting rid of the parent field assumptions is a large > prerequisite for changing inheritance.) >=20 > Regards, > Andreas As long as there are no plans to support multiple inheritance in QOM, this does not seem feasible. If category information does become available in QOM, it will be easy to rip out an extra field, so I don't think we need to keep out help text in the current messed-up state indefinitely until it's available. > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg