From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKUh0-00044S-SX for qemu-devel@nongnu.org; Fri, 13 Sep 2013 10:50:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKUgp-00063f-Jb for qemu-devel@nongnu.org; Fri, 13 Sep 2013 10:49:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKUgp-00063N-Ak for qemu-devel@nongnu.org; Fri, 13 Sep 2013 10:49:43 -0400 Message-ID: <5233260C.4080608@redhat.com> Date: Fri, 13 Sep 2013 16:49:48 +0200 From: Paolo Bonzini 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> <52331A60.9020400@suse.de> In-Reply-To: <52331A60.9020400@suse.de> 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: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: =?UTF-8?B?w4Frb3MgS292w6Fjcw==?= , Alberto Garcia , qemu-devel@nongnu.org Il 13/09/2013 16:00, Andreas F=C3=A4rber ha scritto: >> > 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 followe= d >> > for IndustryPack in the Linux kernel) or the virtio model (where the >> > device remains under hw/char)? Generally we've tried to follow Linu= x >> > for hw/ structure unless maintainers preferred otherwise, so it woul= d >> > prefer the former. > My quest is a) consistency and b) easily finding QOM base device classe= s > 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 i= t > can benefit from any general char device refactorings. Yeah, I agree. But I'm not sure of the benefit of an hw/ipack directory if (a) there is only one class providing the bus and (b) all the classes using the bus (well, there is just one of them) are in the same directory. If any of the two conditions were not true anymore, I'd ask to contextually create hw/ipack. But for now, keeping both ipack files in hw/char is the most "economic" thing to do. Paolo