From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50965) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTBzZ-0004X2-Kw for qemu-devel@nongnu.org; Tue, 09 Feb 2016 12:22:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTBzU-0001pc-MS for qemu-devel@nongnu.org; Tue, 09 Feb 2016 12:22:21 -0500 Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:38024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTBzU-0001p2-A3 for qemu-devel@nongnu.org; Tue, 09 Feb 2016 12:22:16 -0500 Received: by mail-wm0-x22c.google.com with SMTP id p63so32610687wmp.1 for ; Tue, 09 Feb 2016 09:22:16 -0800 (PST) References: From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Tue, 09 Feb 2016 17:22:13 +0000 Message-ID: <8760xxx0hm.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 00/16] data-driven device registers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alistair Francis Cc: edgar.iglesias@xilinx.com, peter.maydell@linaro.org, qemu-devel@nongnu.org, crosthwaitepeter@gmail.com, edgar.iglesias@gmail.com, afaerber@suse.de, fred.konrad@greensocs.com Alistair Francis writes: > This patch series is based on Peter C's original register API. His > original cover letter is below. OK that's my first pass review. I seem to be missing 16/16 in my inbox though. My initial thoughts are it seems pretty useful from a validation point of view. I'm a little uncomfortable with so much of the validation being hidden behind debug statements though. I wonder if they should always be checked but only optionally printed. Otherwise stuff is liable to bit-rot until you turn on debug. Also I'm not super crazy about the macro stuff. I can see what you are trying to get to but I wonder if there is a neater way of defining this. Obviously with C being what it is it could well be it is the least ugly solution. The case for this may be improved if in addition to new devices and existing device could be converted to the data driven style. That would give a nicer old-style <-> new-style comparison. Once you've had a chance to go through the comments and fix up the compile please CC me on future patches and I'll give the tyres a runtime kicking ;-) Cheers, -- Alex Bennée