From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1iaIoA-0003Rr-Bm for mharc-qemu-riscv@gnu.org; Thu, 28 Nov 2019 07:22:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36331) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaIo5-0003Lf-Q4 for qemu-riscv@nongnu.org; Thu, 28 Nov 2019 07:22:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaIo1-0007jI-JS for qemu-riscv@nongnu.org; Thu, 28 Nov 2019 07:21:59 -0500 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:50067 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iaIo1-0007f9-9i for qemu-riscv@nongnu.org; Thu, 28 Nov 2019 07:21:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574943716; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=08Nyj49dE5IDJWQrTCQ66QZcgZEC4k4vNpQuBS0d/I0=; b=QtlmlFG9pQgRWs+af6Oyuo/F4Jy+MNRj/GWsmKsqQYfXmeCypHB+aVpZQc8RH/aV6zYbJn zOZ/7a8y6yuyDsqW4RNkHlHPpk/2DicAeEr/VMe9LhAuEcYFM2Q3yEt2Ns4cmbWHVydVaU SgC7DdgIABax7UPfx/mgOenNweE3ox8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-295-x1qo6n9QNsebkJVM4M17ug-1; Thu, 28 Nov 2019 07:21:54 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 877B5DB20; Thu, 28 Nov 2019 12:21:50 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-116-134.ams2.redhat.com [10.36.116.134]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F0B1F5D9E1; Thu, 28 Nov 2019 12:21:21 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 7B1B41138606; Thu, 28 Nov 2019 13:21:20 +0100 (CET) From: Markus Armbruster To: Vladimir Sementsov-Ogievskiy Cc: Ronnie Sahlberg , Jeff Cody , Jan Kiszka , Alberto Garcia , Hailiang Zhang , "qemu-block\@nongnu.org" , Aleksandar Rikalo , Halil Pasic , =?utf-8?Q?Herv=C3=A9?= Poussineau , Anthony Perard , Samuel Thibault , Laszlo Ersek , Jason Wang , Laurent Vivier , Eduardo Habkost , Xie Changlong , Peter Lieven , "Dr. David Alan Gilbert" , Beniamino Galvani , Eric Auger , Alex Williamson , Stefan Hajnoczi , John Snow , Richard Henderson , Kevin Wolf , Andrew Jeffery , Chris Wulff , Subbaraya Sundeep , Michael Walle , "qemu-ppc\@nongnu.org" , Bastian Koppelmann , Igor Mammedov , Fam Zheng , Peter Maydell , "sheepdog\@lists.wpkg.org" , Matthew Rosato , David Hildenbrand , Palmer Dabbelt , Eric Farman , Max Filippov , Hannes Reinecke , Stefano Stabellini , "Gonglei \(Arei\)" , Liu Yuan , Artyom Tarasenko , Thomas Huth , Amit Shah , Stefan Weil , Greg Kurz , Yuval Shaia , "qemu-s390x\@nongnu.org" , "qemu-arm\@nongnu.org" , Peter Chubb , =?utf-8?Q?C=C3=A9dric?= Le Goater , Stafford Horne , "qemu-riscv\@nongnu.org" , Cornelia Huck , Aleksandar Markovic , Aurelien Jarno , Paul Burton , Sagar Karandikar , Paul Durrant , Anthony Green , Gerd Hoffmann , "Edgar E. Iglesias" , Guan Xuetao , Ari Sundholm , Juan Quintela , Michael Roth , Christian Borntraeger , Joel Stanley , Jason Dillaman , Antony Pavlov , "xen-devel\@lists.xenproject.org" , "integration\@gluster.org" , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , "Richard W.M. Jones" , Andrew Baumann , Max Reitz , Denis Lunev , "Michael S. Tsirkin" , Mark Cave-Ayland , "qemu-devel\@nongnu.org" , Vincenzo Maffione , Marek Vasut , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Alistair Francis , Pavel Dovgalyuk , Giuseppe Lettieri , Luigi Rizzo , David Gibson , Tony Krowiak , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Xiao Guangrong , Pierre Morel , Wen Congyang , Jean-Christophe Dubois , Paolo Bonzini , Stefan Berger Subject: Re: [RFC v5 000/126] error: auto propagated local_err References: <20191011160552.22907-1-vsementsov@virtuozzo.com> <87tv6opehz.fsf@dusky.pond.sub.org> Date: Thu, 28 Nov 2019 13:21:20 +0100 In-Reply-To: (Vladimir Sementsov-Ogievskiy's message of "Thu, 28 Nov 2019 09:20:01 +0000") Message-ID: <87mucgmbsv.fsf@dusky.pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-MC-Unique: x1qo6n9QNsebkJVM4M17ug-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 207.211.31.81 X-BeenThere: qemu-riscv@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 12:22:04 -0000 Vladimir Sementsov-Ogievskiy writes: > 28.11.2019 11:54, Markus Armbruster wrote: >> Please accept my sincere apologies for taking so long to reply. A few >> thoughts before I dig deeper. >>=20 >> Vladimir Sementsov-Ogievskiy writes: >>=20 >>> Hi all! >>> >>> At the request of Markus: full version of errp propagation. Let's look >>> at it. Cover as much as possible, except inserting macro invocation >>> where it's not necessary. >>> >>> It's huge, and so it's an RFC. >>=20 >> It's a monster. Best to get it into full view before we commit to >> fighting it. >>=20 >>> In v5 I've added a lot more preparation cleanups: >>> 01-23 are preparation cleanups >>> 01: not changed, keep Eric's r-b >>> 02: improve commit msg [Markus], keep Eric's r-b >>> 03: changed, only error API here, drop r-b >>> 24 is core macro >>> - improve cover letter, wording and macro code style >>> - keep Eric's r-b >>> 25-26: automation scripts >>> - commit-per-subsystem changed a lot. it's a draft, don't bother to= o >>> much with it >>> - coccinelle: add support of error_propagate_prepend >>> >>> 27-126: generated patches >>=20 >> Splitting up the monster can make fighting it easier. >>=20 >> Your description suggests three high-level parts: >>=20 >> Part 1: Preparation (makes sense by itself) > > I already resent part 1 all patches (handling review comments) in separat= e as v6. > If it is convenient, I can resend them in one series as v7. Recommend to await review. The more we can merge without another respin, the better. >> Part 2: Error interface update (with rules what code should do now) > > Note, that patch 21 is actually from part2, not part1. > So Part 2 is 21, 24, 25. Thanks for the heads-up. > So I wait for your comments and resend (if needed) as separate small seri= es. > > And 26 is auto-patch-splitter, but we don't need it now, if we are going > to start from several big subsystems. > >> Part 3: Make the code obey the new rules everywhere >>=20 >> I hope we can get part 1 out of the way quickly. Diffstat: >>=20 >> backends/cryptodev.c | 11 +--- >> block/nbd.c | 10 +-- >> block/snapshot.c | 4 +- >> dump/dump-hmp-cmds.c | 4 +- >> hw/9pfs/9p-local.c | 4 +- >> hw/9pfs/9p-proxy.c | 5 +- >> hw/core/loader-fit.c | 5 +- >> hw/core/machine-hmp-cmds.c | 6 +- >> hw/core/qdev.c | 28 ++++---- >> hw/i386/amd_iommu.c | 14 ++-- >> hw/ppc/spapr.c | 2 +- >> hw/s390x/event-facility.c | 2 +- >> hw/s390x/s390-stattrib.c | 3 +- >> hw/sd/sdhci.c | 2 +- >> hw/tpm/tpm_emulator.c | 8 +-- >> hw/usb/dev-network.c | 2 +- >> hw/vfio/ap.c | 16 +---- >> include/block/snapshot.h | 2 +- >> include/monitor/hmp.h | 2 +- >> include/qapi/error.h | 69 ++++++++++++++++++-- >> include/qom/object.h | 4 +- >> monitor/hmp-cmds.c | 155 ++++++++++++++++++++++---------------= -------- >> monitor/qmp-cmds.c | 2 +- >> net/net.c | 17 ++--- >> qdev-monitor.c | 28 ++++---- >> qga/commands-posix.c | 2 +- >> qga/commands-win32.c | 2 +- >> qga/commands.c | 12 ++-- >> qom/qom-hmp-cmds.c | 4 +- >> target/ppc/kvm.c | 6 +- >> target/ppc/kvm_ppc.h | 4 +- >> ui/vnc.c | 20 ++---- >> ui/vnc.h | 2 +- >> util/error.c | 30 ++++----- >> 34 files changed, 261 insertions(+), 226 deletions(-) >>=20 >> At first glance, I can see bug fixes, non-mechanical cleanups, and >> mechanical cleanups. >>=20 >> Within each of these three groups, we have related sub-groups. For >> instance, several patches clean up funny names for the common Error ** >> parameters. Several more rename "uncommon" Error ** parameters, to >> signal their uncommon role. I doubt splitting up these subgroups of >> related mechanical changes along subsystem lines is worthwhile. >>=20 >> Part 2 needs careful interface review. Having part 3 ready helps there, >> because we can see rather than guess how the interface changes play out. >> We really want to get this part right from the start, because if we >> don't, we get to do part 3 again. >>=20 >> Part 3 is what makes this a monster. I understand it's mechanical. We >> can merge it incrementally, but we do want to merge it all, and sooner >> rather than later, to avoid a mix of old and new error handling code. >> Such mixes inevitably confuse developers, and lead to new instances of >> the old patterns creeping in. >>=20 >> I do have doubts about your automated split. >>=20 >> I acknowledge maintainers of active subsystems may want to merge this on >> their own terms, to minimize disruption. Splitting off sub-monsters for >> them makes sense. Splitting off the long tail of less busy subsystems >> not so much; it'll only drag out the merging. Your list below shows 100 >> parts, and chasing their maintainers is not going to be a fun >> experience. >>=20 >> Moreover, using MAINTAINERS to guide an automatic split is a cute idea, >> but it falls apart when MAINTAINERS attributes the same file to several >> subsystems, which is fairly common. A sane split requires human touch. >>=20 >> Instead, I'd start with big subsystems with maintainers known to be >> sympathetic to this effort. Split off their sub-monsters, get them >> merged. Iterate until the remainder can be merged in one final push. > > Do you mean to send them as separate per-subsystem series, or all in one, > but limited to some subsystems? Let's make it as easy as we can both for the subsystem maintainers and for the people trying to track all of it. When a subsystem takes multiple patches, I'd consider an independent series to save the maintainer the trouble of extracting multiple patches from a larger series. For the ones that take just one patch, I'd consider an omnibus series. Extracting a single patch is no harder than applying a series, but tracking one omnibus is easier than a dozen lone patches. There's no clear line between "busy" and "less busy" subsystem. Just start with some obviously busy ones, then iterate. Each iteration should be large enough to be worth the overhead, yet small enough not to scare off reviewers :) Trust your judgement! [...] From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a19:6911:0:0:0:0:0 with SMTP id e17csp7506165lfc; Thu, 28 Nov 2019 04:24:10 -0800 (PST) X-Google-Smtp-Source: APXvYqyoD8UOoyRcEgzL/EZugj+FRpip6dEBRy86rKRIAG/wxWaK4BAAYTvIz1cNipc54MqfRg57 X-Received: by 2002:a05:6402:1d8f:: with SMTP id dk15mr8697979edb.29.1574943849975; Thu, 28 Nov 2019 04:24:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574943849; cv=none; d=google.com; s=arc-20160816; b=sficLZ0ewzmEEs1qH9KaIAeab1owKThKqjqgZJoIirxe7YNS8yndLwtpXi0qgRs61U 9Ou7t71dzVsKtx6hmzSZRy3eoGi6ZOYYBLJgGyUP1Q9gQc3sRICKbEjtUPXX1zjY50xd GgppX9Rf983S9wFSioE2ErxAl3L8AfnSctuMzu832n/sio5L1rrE5baupJjMMZbbb+EO 3bsi5o+S8mHTlNyw2IfR4uKq/LaAdZmLLG1qELsLoVCaq/Bn7EzKBe6b4njiaMM0kVY7 3d9h2f5yUy2MErY9TdwYicfObj+TBzS/nNXNg420IP1XIY32g7ZtPEfv7BDQHZcDswtf re2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:user-agent:message-id:in-reply-to:date:references :subject:to:from:dkim-signature; bh=08Nyj49dE5IDJWQrTCQ66QZcgZEC4k4vNpQuBS0d/I0=; b=HK0XAOQkiHUkfi0uTh256AcE+WMFJYJFuoYLHd4oo1lzlSSYq4oFCZUm8n0wKFSJEv mTCPfLv1MdB6RbDZZGmHg/6lBaoCbb8Wl7QZ+QpKIz7SSyRIhlcsNdYtUNB0UB/0QH4j 8/bGK9HRHuCN/uQqel05ilBd3R2kRYQYnkeaffGLrgFYKbOPg5689IxYRVE54ObZmw5s Wv9BOtxT4jULjNUn0eu9zJdiPu+uMu3wVocuqREXuwaiHtMUS1GorSeeb1MxvXe+wyKY BWh0Qg57ZnJrSEN3bnq+HOw4WZzQlFw7UlZvPWE4LNSNfeeRw/m9G2u2nSiM/4DlVWix nBIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@redhat.com header.s=mimecast20190719 header.b=QtlmlFG9; spf=pass (google.com: domain of qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org. [209.51.188.17]) by mx.google.com with ESMTPS id a26si5264502ejr.50.2019.11.28.04.24.09 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 28 Nov 2019 04:24:09 -0800 (PST) Received-SPF: pass (google.com: domain of qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; Authentication-Results: mx.google.com; dkim=fail header.i=@redhat.com header.s=mimecast20190719 header.b=QtlmlFG9; spf=pass (google.com: domain of qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from localhost ([::1]:48432 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaIq4-0003RC-TL for alex.bennee@linaro.org; Thu, 28 Nov 2019 07:24:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36343) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaIo6-0003Lk-Dr for qemu-devel@nongnu.org; Thu, 28 Nov 2019 07:22:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaIo1-0007kG-PQ for qemu-devel@nongnu.org; Thu, 28 Nov 2019 07:21:59 -0500 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:38675 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iaIo1-0007er-9L for qemu-devel@nongnu.org; Thu, 28 Nov 2019 07:21:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574943716; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=08Nyj49dE5IDJWQrTCQ66QZcgZEC4k4vNpQuBS0d/I0=; b=QtlmlFG9pQgRWs+af6Oyuo/F4Jy+MNRj/GWsmKsqQYfXmeCypHB+aVpZQc8RH/aV6zYbJn zOZ/7a8y6yuyDsqW4RNkHlHPpk/2DicAeEr/VMe9LhAuEcYFM2Q3yEt2Ns4cmbWHVydVaU SgC7DdgIABax7UPfx/mgOenNweE3ox8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-295-x1qo6n9QNsebkJVM4M17ug-1; Thu, 28 Nov 2019 07:21:54 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 877B5DB20; Thu, 28 Nov 2019 12:21:50 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-116-134.ams2.redhat.com [10.36.116.134]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F0B1F5D9E1; Thu, 28 Nov 2019 12:21:21 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 7B1B41138606; Thu, 28 Nov 2019 13:21:20 +0100 (CET) From: Markus Armbruster To: Vladimir Sementsov-Ogievskiy Subject: Re: [RFC v5 000/126] error: auto propagated local_err References: <20191011160552.22907-1-vsementsov@virtuozzo.com> <87tv6opehz.fsf@dusky.pond.sub.org> Date: Thu, 28 Nov 2019 13:21:20 +0100 In-Reply-To: (Vladimir Sementsov-Ogievskiy's message of "Thu, 28 Nov 2019 09:20:01 +0000") Message-ID: <87mucgmbsv.fsf@dusky.pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-MC-Unique: x1qo6n9QNsebkJVM4M17ug-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 207.211.31.81 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stefan Hajnoczi , Jeff Cody , Jan Kiszka , Alberto Garcia , Hailiang Zhang , "qemu-block@nongnu.org" , Aleksandar Rikalo , Halil Pasic , =?utf-8?Q?Herv=C3=A9?= Poussineau , Anthony Perard , Samuel Thibault , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Anthony Green , Laurent Vivier , Eduardo Habkost , Xie Changlong , Peter Lieven , "Dr. David Alan Gilbert" , Beniamino Galvani , Eric Auger , Alex Williamson , Ronnie Sahlberg , John Snow , Richard Henderson , Kevin Wolf , Andrew Jeffery , Chris Wulff , Subbaraya Sundeep , Michael Walle , "qemu-ppc@nongnu.org" , Bastian Koppelmann , Igor Mammedov , Fam Zheng , Peter Maydell , "sheepdog@lists.wpkg.org" , Matthew Rosato , David Hildenbrand , Palmer Dabbelt , Eric Farman , Max Filippov , Hannes Reinecke , Stefano Stabellini , "Gonglei \(Arei\)" , Liu Yuan , Artyom Tarasenko , Thomas Huth , Amit Shah , Stefan Weil , Greg Kurz , Yuval Shaia , "qemu-s390x@nongnu.org" , "qemu-arm@nongnu.org" , Peter Chubb , =?utf-8?Q?C=C3=A9dric?= Le Goater , Stafford Horne , "qemu-riscv@nongnu.org" , Cornelia Huck , Aleksandar Markovic , Aurelien Jarno , Paul Burton , Sagar Karandikar , Paul Durrant , Jason Wang , Gerd Hoffmann , "Edgar E. Iglesias" , Guan Xuetao , Ari Sundholm , Juan Quintela , Michael Roth , Christian Borntraeger , Joel Stanley , Jason Dillaman , Antony Pavlov , "xen-devel@lists.xenproject.org" , "integration@gluster.org" , Laszlo Ersek , "Richard W.M. Jones" , Andrew Baumann , Max Reitz , Denis Lunev , "Michael S. Tsirkin" , Mark Cave-Ayland , "qemu-devel@nongnu.org" , Vincenzo Maffione , Marek Vasut , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Alistair Francis , Pavel Dovgalyuk , Giuseppe Lettieri , Luigi Rizzo , David Gibson , Tony Krowiak , "Daniel P. =?utf-8?Q?Berrang=C3=A9?=" , Xiao Guangrong , Pierre Morel , Wen Congyang , Jean-Christophe Dubois , Paolo Bonzini , Stefan Berger Errors-To: qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org Sender: "Qemu-devel" X-TUID: /HtlfDswGV++ Vladimir Sementsov-Ogievskiy writes: > 28.11.2019 11:54, Markus Armbruster wrote: >> Please accept my sincere apologies for taking so long to reply. A few >> thoughts before I dig deeper. >>=20 >> Vladimir Sementsov-Ogievskiy writes: >>=20 >>> Hi all! >>> >>> At the request of Markus: full version of errp propagation. Let's look >>> at it. Cover as much as possible, except inserting macro invocation >>> where it's not necessary. >>> >>> It's huge, and so it's an RFC. >>=20 >> It's a monster. Best to get it into full view before we commit to >> fighting it. >>=20 >>> In v5 I've added a lot more preparation cleanups: >>> 01-23 are preparation cleanups >>> 01: not changed, keep Eric's r-b >>> 02: improve commit msg [Markus], keep Eric's r-b >>> 03: changed, only error API here, drop r-b >>> 24 is core macro >>> - improve cover letter, wording and macro code style >>> - keep Eric's r-b >>> 25-26: automation scripts >>> - commit-per-subsystem changed a lot. it's a draft, don't bother to= o >>> much with it >>> - coccinelle: add support of error_propagate_prepend >>> >>> 27-126: generated patches >>=20 >> Splitting up the monster can make fighting it easier. >>=20 >> Your description suggests three high-level parts: >>=20 >> Part 1: Preparation (makes sense by itself) > > I already resent part 1 all patches (handling review comments) in separat= e as v6. > If it is convenient, I can resend them in one series as v7. Recommend to await review. The more we can merge without another respin, the better. >> Part 2: Error interface update (with rules what code should do now) > > Note, that patch 21 is actually from part2, not part1. > So Part 2 is 21, 24, 25. Thanks for the heads-up. > So I wait for your comments and resend (if needed) as separate small seri= es. > > And 26 is auto-patch-splitter, but we don't need it now, if we are going > to start from several big subsystems. > >> Part 3: Make the code obey the new rules everywhere >>=20 >> I hope we can get part 1 out of the way quickly. Diffstat: >>=20 >> backends/cryptodev.c | 11 +--- >> block/nbd.c | 10 +-- >> block/snapshot.c | 4 +- >> dump/dump-hmp-cmds.c | 4 +- >> hw/9pfs/9p-local.c | 4 +- >> hw/9pfs/9p-proxy.c | 5 +- >> hw/core/loader-fit.c | 5 +- >> hw/core/machine-hmp-cmds.c | 6 +- >> hw/core/qdev.c | 28 ++++---- >> hw/i386/amd_iommu.c | 14 ++-- >> hw/ppc/spapr.c | 2 +- >> hw/s390x/event-facility.c | 2 +- >> hw/s390x/s390-stattrib.c | 3 +- >> hw/sd/sdhci.c | 2 +- >> hw/tpm/tpm_emulator.c | 8 +-- >> hw/usb/dev-network.c | 2 +- >> hw/vfio/ap.c | 16 +---- >> include/block/snapshot.h | 2 +- >> include/monitor/hmp.h | 2 +- >> include/qapi/error.h | 69 ++++++++++++++++++-- >> include/qom/object.h | 4 +- >> monitor/hmp-cmds.c | 155 ++++++++++++++++++++++---------------= -------- >> monitor/qmp-cmds.c | 2 +- >> net/net.c | 17 ++--- >> qdev-monitor.c | 28 ++++---- >> qga/commands-posix.c | 2 +- >> qga/commands-win32.c | 2 +- >> qga/commands.c | 12 ++-- >> qom/qom-hmp-cmds.c | 4 +- >> target/ppc/kvm.c | 6 +- >> target/ppc/kvm_ppc.h | 4 +- >> ui/vnc.c | 20 ++---- >> ui/vnc.h | 2 +- >> util/error.c | 30 ++++----- >> 34 files changed, 261 insertions(+), 226 deletions(-) >>=20 >> At first glance, I can see bug fixes, non-mechanical cleanups, and >> mechanical cleanups. >>=20 >> Within each of these three groups, we have related sub-groups. For >> instance, several patches clean up funny names for the common Error ** >> parameters. Several more rename "uncommon" Error ** parameters, to >> signal their uncommon role. I doubt splitting up these subgroups of >> related mechanical changes along subsystem lines is worthwhile. >>=20 >> Part 2 needs careful interface review. Having part 3 ready helps there, >> because we can see rather than guess how the interface changes play out. >> We really want to get this part right from the start, because if we >> don't, we get to do part 3 again. >>=20 >> Part 3 is what makes this a monster. I understand it's mechanical. We >> can merge it incrementally, but we do want to merge it all, and sooner >> rather than later, to avoid a mix of old and new error handling code. >> Such mixes inevitably confuse developers, and lead to new instances of >> the old patterns creeping in. >>=20 >> I do have doubts about your automated split. >>=20 >> I acknowledge maintainers of active subsystems may want to merge this on >> their own terms, to minimize disruption. Splitting off sub-monsters for >> them makes sense. Splitting off the long tail of less busy subsystems >> not so much; it'll only drag out the merging. Your list below shows 100 >> parts, and chasing their maintainers is not going to be a fun >> experience. >>=20 >> Moreover, using MAINTAINERS to guide an automatic split is a cute idea, >> but it falls apart when MAINTAINERS attributes the same file to several >> subsystems, which is fairly common. A sane split requires human touch. >>=20 >> Instead, I'd start with big subsystems with maintainers known to be >> sympathetic to this effort. Split off their sub-monsters, get them >> merged. Iterate until the remainder can be merged in one final push. > > Do you mean to send them as separate per-subsystem series, or all in one, > but limited to some subsystems? Let's make it as easy as we can both for the subsystem maintainers and for the people trying to track all of it. When a subsystem takes multiple patches, I'd consider an independent series to save the maintainer the trouble of extracting multiple patches from a larger series. For the ones that take just one patch, I'd consider an omnibus series. Extracting a single patch is no harder than applying a series, but tracking one omnibus is easier than a dozen lone patches. There's no clear line between "busy" and "less busy" subsystem. Just start with some obviously busy ones, then iterate. Each iteration should be large enough to be worth the overhead, yet small enough not to scare off reviewers :) Trust your judgement! [...] From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55F26C432C0 for ; Thu, 28 Nov 2019 12:27:03 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 162652158A for ; Thu, 28 Nov 2019 12:27:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="E+kaEFKQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 162652158A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iaIsd-0002bP-Ok; Thu, 28 Nov 2019 12:26:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iaIne-0002UP-P6 for xen-devel@lists.xenproject.org; Thu, 28 Nov 2019 12:21:35 +0000 X-Inumbo-ID: 9d700a20-11d9-11ea-a3d2-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 9d700a20-11d9-11ea-a3d2-12813bfff9fa; Thu, 28 Nov 2019 12:21:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574943693; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=08Nyj49dE5IDJWQrTCQ66QZcgZEC4k4vNpQuBS0d/I0=; b=E+kaEFKQA57J0ieDDMyUUsUZ8DjafLxf17VCGzL4tQWhzdDqpvNyCaIvrDwghPRdH9gSfW i6Nh/FdnEkpD0XnWVRpwNqFiKx1dRNLW0jYeAyyoCFFmrEtHvtf2ve5P5bICs+5FbB8nkK uGkxi/bKgBo+dxBlnVv8nlYPMyZ2tYs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-36-2X6Kw02DNGiyUEdOf5vkNQ-1; Thu, 28 Nov 2019 07:21:30 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 516301800D52; Thu, 28 Nov 2019 12:21:25 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-116-134.ams2.redhat.com [10.36.116.134]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1B0B660BE2; Thu, 28 Nov 2019 12:21:21 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 7B1B41138606; Thu, 28 Nov 2019 13:21:20 +0100 (CET) From: Markus Armbruster To: Vladimir Sementsov-Ogievskiy References: <20191011160552.22907-1-vsementsov@virtuozzo.com> <87tv6opehz.fsf@dusky.pond.sub.org> Date: Thu, 28 Nov 2019 13:21:20 +0100 In-Reply-To: (Vladimir Sementsov-Ogievskiy's message of "Thu, 28 Nov 2019 09:20:01 +0000") Message-ID: <87mucgmbsv.fsf@dusky.pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-MC-Unique: 2X6Kw02DNGiyUEdOf5vkNQ-1 X-Mimecast-Spam-Score: 0 X-Mailman-Approved-At: Thu, 28 Nov 2019 12:26:42 +0000 Subject: Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefan Hajnoczi , Jeff Cody , Jan Kiszka , Alberto Garcia , Hailiang Zhang , "qemu-block@nongnu.org" , Aleksandar Rikalo , Halil Pasic , =?utf-8?Q?Herv=C3=A9?= Poussineau , Anthony Perard , Samuel Thibault , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Anthony Green , Laurent Vivier , Eduardo Habkost , Xie Changlong , Peter Lieven , "Dr. David Alan Gilbert" , Beniamino Galvani , Eric Auger , Alex Williamson , Ronnie Sahlberg , John Snow , Richard Henderson , Kevin Wolf , Andrew Jeffery , Chris Wulff , Subbaraya Sundeep , Michael Walle , "qemu-ppc@nongnu.org" , Bastian Koppelmann , Igor Mammedov , Fam Zheng , Peter Maydell , "sheepdog@lists.wpkg.org" , Matthew Rosato , David Hildenbrand , Palmer Dabbelt , Eric Farman , Max Filippov , Hannes Reinecke , Stefano Stabellini , "Gonglei \(Arei\)" , Liu Yuan , Artyom Tarasenko , Thomas Huth , Amit Shah , Stefan Weil , Greg Kurz , Yuval Shaia , "qemu-s390x@nongnu.org" , "qemu-arm@nongnu.org" , Peter Chubb , =?utf-8?Q?C=C3=A9dric?= Le Goater , Stafford Horne , "qemu-riscv@nongnu.org" , Cornelia Huck , Aleksandar Markovic , Aurelien Jarno , Paul Burton , Sagar Karandikar , Paul Durrant , Jason Wang , Gerd Hoffmann , "Edgar E. Iglesias" , Guan Xuetao , Ari Sundholm , Juan Quintela , Michael Roth , Christian Borntraeger , Joel Stanley , Jason Dillaman , Antony Pavlov , "xen-devel@lists.xenproject.org" , "integration@gluster.org" , Laszlo Ersek , "Richard W.M. Jones" , Andrew Baumann , Max Reitz , Denis Lunev , "Michael S. Tsirkin" , Mark Cave-Ayland , "qemu-devel@nongnu.org" , Vincenzo Maffione , Marek Vasut , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Alistair Francis , Pavel Dovgalyuk , Giuseppe Lettieri , Luigi Rizzo , David Gibson , Tony Krowiak , "Daniel P. =?utf-8?Q?Berrang=C3=A9?=" , Xiao Guangrong , Pierre Morel , Wen Congyang , Jean-Christophe Dubois , Paolo Bonzini , Stefan Berger Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" VmxhZGltaXIgU2VtZW50c292LU9naWV2c2tpeSA8dnNlbWVudHNvdkB2aXJ0dW96em8uY29tPiB3 cml0ZXM6Cgo+IDI4LjExLjIwMTkgMTE6NTQsIE1hcmt1cyBBcm1icnVzdGVyIHdyb3RlOgo+PiBQ bGVhc2UgYWNjZXB0IG15IHNpbmNlcmUgYXBvbG9naWVzIGZvciB0YWtpbmcgc28gbG9uZyB0byBy ZXBseS4gIEEgZmV3Cj4+IHRob3VnaHRzIGJlZm9yZSBJIGRpZyBkZWVwZXIuCj4+IAo+PiBWbGFk aW1pciBTZW1lbnRzb3YtT2dpZXZza2l5IDx2c2VtZW50c292QHZpcnR1b3p6by5jb20+IHdyaXRl czoKPj4gCj4+PiBIaSBhbGwhCj4+Pgo+Pj4gQXQgdGhlIHJlcXVlc3Qgb2YgTWFya3VzOiBmdWxs IHZlcnNpb24gb2YgZXJycCBwcm9wYWdhdGlvbi4gTGV0J3MgbG9vawo+Pj4gYXQgaXQuIENvdmVy IGFzIG11Y2ggYXMgcG9zc2libGUsIGV4Y2VwdCBpbnNlcnRpbmcgbWFjcm8gaW52b2NhdGlvbgo+ Pj4gd2hlcmUgaXQncyBub3QgbmVjZXNzYXJ5Lgo+Pj4KPj4+IEl0J3MgaHVnZSwgYW5kIHNvIGl0 J3MgYW4gUkZDLgo+PiAKPj4gSXQncyBhIG1vbnN0ZXIuICBCZXN0IHRvIGdldCBpdCBpbnRvIGZ1 bGwgdmlldyBiZWZvcmUgd2UgY29tbWl0IHRvCj4+IGZpZ2h0aW5nIGl0Lgo+PiAKPj4+IEluIHY1 IEkndmUgYWRkZWQgYSBsb3QgbW9yZSBwcmVwYXJhdGlvbiBjbGVhbnVwczoKPj4+IDAxLTIzIGFy ZSBwcmVwYXJhdGlvbiBjbGVhbnVwcwo+Pj4gICAgMDE6IG5vdCBjaGFuZ2VkLCBrZWVwIEVyaWMn cyByLWIKPj4+ICAgIDAyOiBpbXByb3ZlIGNvbW1pdCBtc2cgW01hcmt1c10sIGtlZXAgRXJpYydz IHItYgo+Pj4gICAgMDM6IGNoYW5nZWQsIG9ubHkgZXJyb3IgQVBJIGhlcmUsIGRyb3Agci1iCj4+ PiAyNCBpcyBjb3JlIG1hY3JvCj4+PiAgICAtIGltcHJvdmUgY292ZXIgbGV0dGVyLCB3b3JkaW5n IGFuZCBtYWNybyBjb2RlIHN0eWxlCj4+PiAgICAtIGtlZXAgRXJpYydzIHItYgo+Pj4gMjUtMjY6 IGF1dG9tYXRpb24gc2NyaXB0cwo+Pj4gICAgIC0gY29tbWl0LXBlci1zdWJzeXN0ZW0gY2hhbmdl ZCBhIGxvdC4gaXQncyBhIGRyYWZ0LCBkb24ndCBib3RoZXIgdG9vCj4+PiAgICAgICBtdWNoIHdp dGggaXQKPj4+ICAgICAtIGNvY2NpbmVsbGU6IGFkZCBzdXBwb3J0IG9mIGVycm9yX3Byb3BhZ2F0 ZV9wcmVwZW5kCj4+Pgo+Pj4gMjctMTI2OiBnZW5lcmF0ZWQgcGF0Y2hlcwo+PiAKPj4gU3BsaXR0 aW5nIHVwIHRoZSBtb25zdGVyIGNhbiBtYWtlIGZpZ2h0aW5nIGl0IGVhc2llci4KPj4gCj4+IFlv dXIgZGVzY3JpcHRpb24gc3VnZ2VzdHMgdGhyZWUgaGlnaC1sZXZlbCBwYXJ0czoKPj4gCj4+IFBh cnQgMTogUHJlcGFyYXRpb24gKG1ha2VzIHNlbnNlIGJ5IGl0c2VsZikKPgo+IEkgYWxyZWFkeSBy ZXNlbnQgcGFydCAxIGFsbCBwYXRjaGVzIChoYW5kbGluZyByZXZpZXcgY29tbWVudHMpIGluIHNl cGFyYXRlIGFzIHY2Lgo+IElmIGl0IGlzIGNvbnZlbmllbnQsIEkgY2FuIHJlc2VuZCB0aGVtIGlu IG9uZSBzZXJpZXMgYXMgdjcuCgpSZWNvbW1lbmQgdG8gYXdhaXQgcmV2aWV3LiAgVGhlIG1vcmUg d2UgY2FuIG1lcmdlIHdpdGhvdXQgYW5vdGhlcgpyZXNwaW4sIHRoZSBiZXR0ZXIuCgo+PiBQYXJ0 IDI6IEVycm9yIGludGVyZmFjZSB1cGRhdGUgKHdpdGggcnVsZXMgd2hhdCBjb2RlIHNob3VsZCBk byBub3cpCj4KPiBOb3RlLCB0aGF0IHBhdGNoIDIxIGlzIGFjdHVhbGx5IGZyb20gcGFydDIsIG5v dCBwYXJ0MS4KPiBTbyBQYXJ0IDIgaXMgMjEsIDI0LCAyNS4KClRoYW5rcyBmb3IgdGhlIGhlYWRz LXVwLgoKPiBTbyBJIHdhaXQgZm9yIHlvdXIgY29tbWVudHMgYW5kIHJlc2VuZCAoaWYgbmVlZGVk KSBhcyBzZXBhcmF0ZSBzbWFsbCBzZXJpZXMuCj4KPiBBbmQgMjYgaXMgYXV0by1wYXRjaC1zcGxp dHRlciwgYnV0IHdlIGRvbid0IG5lZWQgaXQgbm93LCBpZiB3ZSBhcmUgZ29pbmcKPiB0byBzdGFy dCBmcm9tIHNldmVyYWwgYmlnIHN1YnN5c3RlbXMuCj4KPj4gUGFydCAzOiBNYWtlIHRoZSBjb2Rl IG9iZXkgdGhlIG5ldyBydWxlcyBldmVyeXdoZXJlCj4+IAo+PiBJIGhvcGUgd2UgY2FuIGdldCBw YXJ0IDEgb3V0IG9mIHRoZSB3YXkgcXVpY2tseS4gIERpZmZzdGF0Ogo+PiAKPj4gICBiYWNrZW5k cy9jcnlwdG9kZXYuYyAgICAgICB8ICAxMSArLS0tCj4+ICAgYmxvY2svbmJkLmMgICAgICAgICAg ICAgICAgfCAgMTAgKy0tCj4+ICAgYmxvY2svc25hcHNob3QuYyAgICAgICAgICAgfCAgIDQgKy0K Pj4gICBkdW1wL2R1bXAtaG1wLWNtZHMuYyAgICAgICB8ICAgNCArLQo+PiAgIGh3LzlwZnMvOXAt bG9jYWwuYyAgICAgICAgIHwgICA0ICstCj4+ICAgaHcvOXBmcy85cC1wcm94eS5jICAgICAgICAg fCAgIDUgKy0KPj4gICBody9jb3JlL2xvYWRlci1maXQuYyAgICAgICB8ICAgNSArLQo+PiAgIGh3 L2NvcmUvbWFjaGluZS1obXAtY21kcy5jIHwgICA2ICstCj4+ICAgaHcvY29yZS9xZGV2LmMgICAg ICAgICAgICAgfCAgMjggKysrKy0tLS0KPj4gICBody9pMzg2L2FtZF9pb21tdS5jICAgICAgICB8 ICAxNCArKy0tCj4+ICAgaHcvcHBjL3NwYXByLmMgICAgICAgICAgICAgfCAgIDIgKy0KPj4gICBo dy9zMzkweC9ldmVudC1mYWNpbGl0eS5jICB8ICAgMiArLQo+PiAgIGh3L3MzOTB4L3MzOTAtc3Rh dHRyaWIuYyAgIHwgICAzICstCj4+ICAgaHcvc2Qvc2RoY2kuYyAgICAgICAgICAgICAgfCAgIDIg Ky0KPj4gICBody90cG0vdHBtX2VtdWxhdG9yLmMgICAgICB8ICAgOCArLS0KPj4gICBody91c2Iv ZGV2LW5ldHdvcmsuYyAgICAgICB8ICAgMiArLQo+PiAgIGh3L3ZmaW8vYXAuYyAgICAgICAgICAg ICAgIHwgIDE2ICstLS0tCj4+ICAgaW5jbHVkZS9ibG9jay9zbmFwc2hvdC5oICAgfCAgIDIgKy0K Pj4gICBpbmNsdWRlL21vbml0b3IvaG1wLmggICAgICB8ICAgMiArLQo+PiAgIGluY2x1ZGUvcWFw aS9lcnJvci5oICAgICAgIHwgIDY5ICsrKysrKysrKysrKysrKysrKy0tCj4+ICAgaW5jbHVkZS9x b20vb2JqZWN0LmggICAgICAgfCAgIDQgKy0KPj4gICBtb25pdG9yL2htcC1jbWRzLmMgICAgICAg ICB8IDE1NSArKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4g ICBtb25pdG9yL3FtcC1jbWRzLmMgICAgICAgICB8ICAgMiArLQo+PiAgIG5ldC9uZXQuYyAgICAg ICAgICAgICAgICAgIHwgIDE3ICsrLS0tCj4+ICAgcWRldi1tb25pdG9yLmMgICAgICAgICAgICAg fCAgMjggKysrKy0tLS0KPj4gICBxZ2EvY29tbWFuZHMtcG9zaXguYyAgICAgICB8ICAgMiArLQo+ PiAgIHFnYS9jb21tYW5kcy13aW4zMi5jICAgICAgIHwgICAyICstCj4+ICAgcWdhL2NvbW1hbmRz LmMgICAgICAgICAgICAgfCAgMTIgKystLQo+PiAgIHFvbS9xb20taG1wLWNtZHMuYyAgICAgICAg IHwgICA0ICstCj4+ICAgdGFyZ2V0L3BwYy9rdm0uYyAgICAgICAgICAgfCAgIDYgKy0KPj4gICB0 YXJnZXQvcHBjL2t2bV9wcGMuaCAgICAgICB8ICAgNCArLQo+PiAgIHVpL3ZuYy5jICAgICAgICAg ICAgICAgICAgIHwgIDIwICsrLS0tLQo+PiAgIHVpL3ZuYy5oICAgICAgICAgICAgICAgICAgIHwg ICAyICstCj4+ICAgdXRpbC9lcnJvci5jICAgICAgICAgICAgICAgfCAgMzAgKysrKy0tLS0tCj4+ ICAgMzQgZmlsZXMgY2hhbmdlZCwgMjYxIGluc2VydGlvbnMoKyksIDIyNiBkZWxldGlvbnMoLSkK Pj4gCj4+IEF0IGZpcnN0IGdsYW5jZSwgSSBjYW4gc2VlIGJ1ZyBmaXhlcywgbm9uLW1lY2hhbmlj YWwgY2xlYW51cHMsIGFuZAo+PiBtZWNoYW5pY2FsIGNsZWFudXBzLgo+PiAKPj4gV2l0aGluIGVh Y2ggb2YgdGhlc2UgdGhyZWUgZ3JvdXBzLCB3ZSBoYXZlIHJlbGF0ZWQgc3ViLWdyb3Vwcy4gIEZv cgo+PiBpbnN0YW5jZSwgc2V2ZXJhbCBwYXRjaGVzIGNsZWFuIHVwIGZ1bm55IG5hbWVzIGZvciB0 aGUgY29tbW9uIEVycm9yICoqCj4+IHBhcmFtZXRlcnMuICBTZXZlcmFsIG1vcmUgcmVuYW1lICJ1 bmNvbW1vbiIgRXJyb3IgKiogcGFyYW1ldGVycywgdG8KPj4gc2lnbmFsIHRoZWlyIHVuY29tbW9u IHJvbGUuICBJIGRvdWJ0IHNwbGl0dGluZyB1cCB0aGVzZSBzdWJncm91cHMgb2YKPj4gcmVsYXRl ZCBtZWNoYW5pY2FsIGNoYW5nZXMgYWxvbmcgc3Vic3lzdGVtIGxpbmVzIGlzIHdvcnRod2hpbGUu Cj4+IAo+PiBQYXJ0IDIgbmVlZHMgY2FyZWZ1bCBpbnRlcmZhY2UgcmV2aWV3LiAgSGF2aW5nIHBh cnQgMyByZWFkeSBoZWxwcyB0aGVyZSwKPj4gYmVjYXVzZSB3ZSBjYW4gc2VlIHJhdGhlciB0aGFu IGd1ZXNzIGhvdyB0aGUgaW50ZXJmYWNlIGNoYW5nZXMgcGxheSBvdXQuCj4+IFdlIHJlYWxseSB3 YW50IHRvIGdldCB0aGlzIHBhcnQgcmlnaHQgZnJvbSB0aGUgc3RhcnQsIGJlY2F1c2UgaWYgd2UK Pj4gZG9uJ3QsIHdlIGdldCB0byBkbyBwYXJ0IDMgYWdhaW4uCj4+IAo+PiBQYXJ0IDMgaXMgd2hh dCBtYWtlcyB0aGlzIGEgbW9uc3Rlci4gIEkgdW5kZXJzdGFuZCBpdCdzIG1lY2hhbmljYWwuICBX ZQo+PiBjYW4gbWVyZ2UgaXQgaW5jcmVtZW50YWxseSwgYnV0IHdlIGRvIHdhbnQgdG8gbWVyZ2Ug aXQgYWxsLCBhbmQgc29vbmVyCj4+IHJhdGhlciB0aGFuIGxhdGVyLCB0byBhdm9pZCBhIG1peCBv ZiBvbGQgYW5kIG5ldyBlcnJvciBoYW5kbGluZyBjb2RlLgo+PiBTdWNoIG1peGVzIGluZXZpdGFi bHkgY29uZnVzZSBkZXZlbG9wZXJzLCBhbmQgbGVhZCB0byBuZXcgaW5zdGFuY2VzIG9mCj4+IHRo ZSBvbGQgcGF0dGVybnMgY3JlZXBpbmcgaW4uCj4+IAo+PiBJIGRvIGhhdmUgZG91YnRzIGFib3V0 IHlvdXIgYXV0b21hdGVkIHNwbGl0Lgo+PiAKPj4gSSBhY2tub3dsZWRnZSBtYWludGFpbmVycyBv ZiBhY3RpdmUgc3Vic3lzdGVtcyBtYXkgd2FudCB0byBtZXJnZSB0aGlzIG9uCj4+IHRoZWlyIG93 biB0ZXJtcywgdG8gbWluaW1pemUgZGlzcnVwdGlvbi4gIFNwbGl0dGluZyBvZmYgc3ViLW1vbnN0 ZXJzIGZvcgo+PiB0aGVtIG1ha2VzIHNlbnNlLiAgU3BsaXR0aW5nIG9mZiB0aGUgbG9uZyB0YWls IG9mIGxlc3MgYnVzeSBzdWJzeXN0ZW1zCj4+IG5vdCBzbyBtdWNoOyBpdCdsbCBvbmx5IGRyYWcg b3V0IHRoZSBtZXJnaW5nLiAgWW91ciBsaXN0IGJlbG93IHNob3dzIDEwMAo+PiBwYXJ0cywgYW5k IGNoYXNpbmcgdGhlaXIgbWFpbnRhaW5lcnMgaXMgbm90IGdvaW5nIHRvIGJlIGEgZnVuCj4+IGV4 cGVyaWVuY2UuCj4+IAo+PiBNb3Jlb3ZlciwgdXNpbmcgTUFJTlRBSU5FUlMgdG8gZ3VpZGUgYW4g YXV0b21hdGljIHNwbGl0IGlzIGEgY3V0ZSBpZGVhLAo+PiBidXQgaXQgZmFsbHMgYXBhcnQgd2hl biBNQUlOVEFJTkVSUyBhdHRyaWJ1dGVzIHRoZSBzYW1lIGZpbGUgdG8gc2V2ZXJhbAo+PiBzdWJz eXN0ZW1zLCB3aGljaCBpcyBmYWlybHkgY29tbW9uLiAgQSBzYW5lIHNwbGl0IHJlcXVpcmVzIGh1 bWFuIHRvdWNoLgo+PiAKPj4gSW5zdGVhZCwgSSdkIHN0YXJ0IHdpdGggYmlnIHN1YnN5c3RlbXMg d2l0aCBtYWludGFpbmVycyBrbm93biB0byBiZQo+PiBzeW1wYXRoZXRpYyB0byB0aGlzIGVmZm9y dC4gIFNwbGl0IG9mZiB0aGVpciBzdWItbW9uc3RlcnMsIGdldCB0aGVtCj4+IG1lcmdlZC4gIEl0 ZXJhdGUgdW50aWwgdGhlIHJlbWFpbmRlciBjYW4gYmUgbWVyZ2VkIGluIG9uZSBmaW5hbCBwdXNo Lgo+Cj4gRG8geW91IG1lYW4gdG8gc2VuZCB0aGVtIGFzIHNlcGFyYXRlIHBlci1zdWJzeXN0ZW0g c2VyaWVzLCBvciBhbGwgaW4gb25lLAo+IGJ1dCBsaW1pdGVkIHRvIHNvbWUgc3Vic3lzdGVtcz8K CkxldCdzIG1ha2UgaXQgYXMgZWFzeSBhcyB3ZSBjYW4gYm90aCBmb3IgdGhlIHN1YnN5c3RlbSBt YWludGFpbmVycyBhbmQKZm9yIHRoZSBwZW9wbGUgdHJ5aW5nIHRvIHRyYWNrIGFsbCBvZiBpdC4K CldoZW4gYSBzdWJzeXN0ZW0gdGFrZXMgbXVsdGlwbGUgcGF0Y2hlcywgSSdkIGNvbnNpZGVyIGFu IGluZGVwZW5kZW50CnNlcmllcyB0byBzYXZlIHRoZSBtYWludGFpbmVyIHRoZSB0cm91YmxlIG9m IGV4dHJhY3RpbmcgbXVsdGlwbGUgcGF0Y2hlcwpmcm9tIGEgbGFyZ2VyIHNlcmllcy4KCkZvciB0 aGUgb25lcyB0aGF0IHRha2UganVzdCBvbmUgcGF0Y2gsIEknZCBjb25zaWRlciBhbiBvbW5pYnVz IHNlcmllcy4KRXh0cmFjdGluZyBhIHNpbmdsZSBwYXRjaCBpcyBubyBoYXJkZXIgdGhhbiBhcHBs eWluZyBhIHNlcmllcywgYnV0CnRyYWNraW5nIG9uZSBvbW5pYnVzIGlzIGVhc2llciB0aGFuIGEg ZG96ZW4gbG9uZSBwYXRjaGVzLgoKVGhlcmUncyBubyBjbGVhciBsaW5lIGJldHdlZW4gImJ1c3ki IGFuZCAibGVzcyBidXN5IiBzdWJzeXN0ZW0uICBKdXN0CnN0YXJ0IHdpdGggc29tZSBvYnZpb3Vz bHkgYnVzeSBvbmVzLCB0aGVuIGl0ZXJhdGUuICBFYWNoIGl0ZXJhdGlvbgpzaG91bGQgYmUgbGFy Z2UgZW5vdWdoIHRvIGJlIHdvcnRoIHRoZSBvdmVyaGVhZCwgeWV0IHNtYWxsIGVub3VnaCBub3Qg dG8Kc2NhcmUgb2ZmIHJldmlld2VycyA6KQoKVHJ1c3QgeW91ciBqdWRnZW1lbnQhCgpbLi4uXQoK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHBzOi8vbGlz dHMueGVucHJvamVjdC5vcmcvbWFpbG1hbi9saXN0aW5mby94ZW4tZGV2ZWw=