From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKU8B-00041V-IE for qemu-devel@nongnu.org; Fri, 13 Sep 2013 10:14:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKU84-0003Id-8Q for qemu-devel@nongnu.org; Fri, 13 Sep 2013 10:13:55 -0400 Received: from cantor2.suse.de ([195.135.220.15]:58276 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKU83-0003IY-Vh for qemu-devel@nongnu.org; Fri, 13 Sep 2013 10:13:48 -0400 Message-ID: <52331A60.9020400@suse.de> Date: Fri, 13 Sep 2013 16:00:00 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1377471536-12423-1-git-send-email-akoskovacs@gmx.com> <1377471536-12423-22-git-send-email-akoskovacs@gmx.com> <521B316E.6070703@redhat.com> <521B8D3E.4080106@suse.de> <521BD95F.4030708@redhat.com> In-Reply-To: <521BD95F.4030708@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 21/47] hw/char/Kconfig: Add Kconfig file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: =?UTF-8?B?w4Frb3MgS292w6Fjcw==?= , Alberto Garcia , qemu-devel@nongnu.org Am 27.08.2013 00:40, schrieb Paolo Bonzini: > Il 26/08/2013 19:15, Andreas F=C3=A4rber ha scritto: >>>> PCI devices are generally configurable, so you need to add prompts t= o them. >> IndustryPack is really misplaced in hw/char/ and I believe I posted >> patches to remedy that and let one actually find it in our source tree= . >> There were no objections against hw/ipack/, alternatively it could go >> into hw/gpio/. (Currently my patch series is waiting to be respun due = to >> changed QOM realize requirements from Anthony.) >> >> That having being said, IndustryPack does not depend on PCI, only the >> TPCI2000(?) PCI-IndustryPack bridge does. >=20 > Both of them are under the same symbol right now. After all any of the > two is basically unusable without the other, and plans for extension > seem not to exist as even Linux has only that one bridge and one device= . >=20 > I have no objection to hw/ipack, but I have a question. Would you > follow the SCSI/USB model (with devices under hw/ipack, also followed > for IndustryPack in the Linux kernel) or the virtio model (where the > device remains under hw/char)? Generally we've tried to follow Linux > for hw/ structure unless maintainers preferred otherwise, so it would > prefer the former. My quest is a) consistency and b) easily finding QOM base device classes for refactorings. PCI and USB were done before your big hw/ reorganization, and the biggest part of devices appears to follow the categorization by function (which is why I saw the overlap with Marcel's category markup). ipoctal232 looks correct in hw/char/ to me, so that it can benefit from any general char device refactorings. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg