From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEGhr-00040N-Tk for qemu-devel@nongnu.org; Mon, 04 Aug 2014 07:45:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XEGhl-0005Ye-H5 for qemu-devel@nongnu.org; Mon, 04 Aug 2014 07:45:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEGhl-0005YQ-28 for qemu-devel@nongnu.org; Mon, 04 Aug 2014 07:45:29 -0400 Date: Mon, 4 Aug 2014 17:15:00 +0530 From: Amit Shah Message-ID: <20140804114500.GP18947@grmbl.mre> References: <874mxs32vv.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874mxs32vv.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH 1/2] virtio-serial: create a linked list of all active devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Amos Kong , qemu list , Andreas =?iso-8859-1?Q?F=E4rber?= On (Mon) 04 Aug 2014 [13:33:56], Markus Armbruster wrote: > Amit Shah writes: > > > To ensure two virtserialports don't get added to the system with the > > same 'name' parameter, we need to access all the ports on all the > > devices added, and compare the names. > > > > We currently don't have a list of all VirtIOSerial devices added to the > > system. This commit adds a simple linked list in which devices are put > > when they're initialized, and removed when they go away. > > +struct VirtIOSerialDevices { > > + QLIST_HEAD(, VirtIOSerial) devices; > > +} vserdevices; > > + > > Any particular reason for stuffing the list into a struct? Not strictly needed for this patch alone, but I think it's cleaner to keep it this way, and when something else comes up that needs a per-device variable, this list will be around. Also, this is also the way it's done in the kernel, so that uniformity helps as well. > Patch looks simple & safe to me, but I can't help to wonder whether want > (or already have?) more generic infrastructure offering "for all devices > of a certain kind" functionality, which is what 2/2 needs. Andreas? Yea; I didn't find any, but if there's already something it can be put to good use here. Thanks, Amit