Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
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. >> >> Vladimir Sementsov-Ogievskiy writes: >> >>> 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. >> >> It's a monster. Best to get it into full view before we commit to >> fighting it. >> >>> 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 too >>> much with it >>> - coccinelle: add support of error_propagate_prepend >>> >>> 27-126: generated patches >> >> Splitting up the monster can make fighting it easier. >> >> Your description suggests three high-level parts: >> >> Part 1: Preparation (makes sense by itself) > > I already resent part 1 all patches (handling review comments) in separate 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 series. > > 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 >> >> I hope we can get part 1 out of the way quickly. Diffstat: >> >> 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(-) >> >> At first glance, I can see bug fixes, non-mechanical cleanups, and >> mechanical cleanups. >> >> 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. >> >> 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. >> >> 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. >> >> I do have doubts about your automated split. >> >> 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
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
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. > > Vladimir Sementsov-Ogievskiy writes: > >> 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. > > It's a monster. Best to get it into full view before we commit to > fighting it. > >> 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 too >> much with it >> - coccinelle: add support of error_propagate_prepend >> >> 27-126: generated patches > > Splitting up the monster can make fighting it easier. > > Your description suggests three high-level parts: > > Part 1: Preparation (makes sense by itself) I already resent part 1 all patches (handling review comments) in separate as v6. If it is convenient, I can resend them in one series as v7. > 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. So I wait for your comments and resend (if needed) as separate small series. 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 > > I hope we can get part 1 out of the way quickly. Diffstat: > > 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(-) > > At first glance, I can see bug fixes, non-mechanical cleanups, and > mechanical cleanups. > > 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. > > 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. > > 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. > > I do have doubts about your automated split. > > 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. > > 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
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
Please accept my sincere apologies for taking so long to reply. A few thoughts before I dig deeper. Vladimir Sementsov-Ogievskiy writes: > 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. It's a monster. Best to get it into full view before we commit to fighting it. > 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 too > much with it >- coccinelle: add support of error_propagate_prepend > > 27-126: generated patches Splitting up the monster can make fighting it easier. Your description suggests three high-level parts: Part 1: Preparation (makes sense by itself) Part 2: Error interface update (with rules what code should do now) Part 3: Make the code obey the new rules everywhere I hope we can get part 1 out of the way quickly. Diffstat: 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(-) At first glance, I can see bug fixes, non-mechanical cleanups, and mechanical cleanups. 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. 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. 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. I do have doubts about your automated split. 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. 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. 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. > > > Here is a proposal of auto propagation for local_err, to not call > error_propagate on every exit point, when we deal with local_err. More cleverness, less code, avoids one kind of error (forgetting manual propagate when we should), risks another kind of error (automatic propagate when we shouldn't). Tradeoffs, but the general feeling among reviewers appears to be positive. > There are also two issues with errp: > > 1. error_fatal &
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
Am 20.11.2019 um 13:59 hat Eric Blake geschrieben: > On 11/20/19 3:50 AM, Vladimir Sementsov-Ogievskiy wrote: > > Okay... > > > > I think that: > > > > 1. A lot of efforts (not only my, I think reviewing is already exceeded > > generation efforts) > > are made, it would be sad to lose them. > > > > 2. It's safe enough to apply only part of generated patches: we just fix > > error_abort/error_fatal > > in more popular subsystems, what's wrong with that? Why not to cover > > 80% cases by 20% efforts? > > > > 3. It's obviously impossible to merge the whole series. A lot of time > > passed, series diverges. > > > > > > So I propose the following plan: > > > > 1. I resend small separate series of preparation patches per maintainer. > > They are good anyway. > > > > 2. We commit patch with macro (changing MUST to SHOULD in documentation) > > and coccinelle script. > > (or that may be combined with the first series from [3.]) > > > > 3. When one of preparations taken to maintainer's tree, I send generated > > patches for > > its maintainer. > > I'd still prefer waiting for direction from Markus. We've been tied up by > other things (KVM Forum, 4.2 release), but now that we are in freeze, this > is actually a GOOD time for Markus to finally get back to this series, and > there is going to be less rebasing needed if we can apply the entire cleanup > right as 5.0 development opens in a couple of weeks. Actually, that's possibly the worst possible time for avoiding conflicts because during freeze, maintainers are collecting stuff in private branches for weeks without getting it into master. If you are the one who gets merged first (what are the odds?), that solves the problem for you, but then everyone else will get conflicts. I like Vladimir's new plan. Kevin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
On 11/20/19 3:50 AM, Vladimir Sementsov-Ogievskiy wrote: Okay... I think that: 1. A lot of efforts (not only my, I think reviewing is already exceeded generation efforts) are made, it would be sad to lose them. 2. It's safe enough to apply only part of generated patches: we just fix error_abort/error_fatal in more popular subsystems, what's wrong with that? Why not to cover 80% cases by 20% efforts? 3. It's obviously impossible to merge the whole series. A lot of time passed, series diverges. So I propose the following plan: 1. I resend small separate series of preparation patches per maintainer. They are good anyway. 2. We commit patch with macro (changing MUST to SHOULD in documentation) and coccinelle script. (or that may be combined with the first series from [3.]) 3. When one of preparations taken to maintainer's tree, I send generated patches for its maintainer. I'd still prefer waiting for direction from Markus. We've been tied up by other things (KVM Forum, 4.2 release), but now that we are in freeze, this is actually a GOOD time for Markus to finally get back to this series, and there is going to be less rebasing needed if we can apply the entire cleanup right as 5.0 development opens in a couple of weeks. If no objections during a week, I'll start that plan, hope someone will support it. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
Okay... I think that: 1. A lot of efforts (not only my, I think reviewing is already exceeded generation efforts) are made, it would be sad to lose them. 2. It's safe enough to apply only part of generated patches: we just fix error_abort/error_fatal in more popular subsystems, what's wrong with that? Why not to cover 80% cases by 20% efforts? 3. It's obviously impossible to merge the whole series. A lot of time passed, series diverges. So I propose the following plan: 1. I resend small separate series of preparation patches per maintainer. They are good anyway. 2. We commit patch with macro (changing MUST to SHOULD in documentation) and coccinelle script. (or that may be combined with the first series from [3.]) 3. When one of preparations taken to maintainer's tree, I send generated patches for its maintainer. If no objections during a week, I'll start that plan, hope someone will support it. 08.11.2019 18:30, Vladimir Sementsov-Ogievskiy wrote: > Finally, what is the plan? > > Markus what do you think? > > Now a lot of patches are reviewed, but a lot of are not. > > Is there any hope that all patches will be reviewed? Should I resend the > whole series, or may be reduce it to reviewed subsystems only? > > 11.10.2019 19:03, Vladimir Sementsov-Ogievskiy wrote: >> 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. >> >> 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 too >> much with it >> - coccinelle: add support of error_propagate_prepend >> >> 27-126: generated patches >> >> >> >> Here is a proposal of auto propagation for local_err, to not call >> error_propagate on every exit point, when we deal with local_err. >> >> There are also two issues with errp: >> >> 1. error_fatal & error_append_hint/error_prepend: user can't see this >> additional info, because exit() happens in error_setg earlier than info >> is added. [Reported by Greg Kurz] >> >> 2. error_abort & error_propagate: when we wrap >> error_abort by local_err+error_propagate, resulting coredump will >> refer to error_propagate and not to the place where error happened. >> (the macro itself don't fix the issue, but it allows to [3.] drop all >> local_err+error_propagate pattern, which will definitely fix the issue) >> [Reported by Kevin Wolf] >> >> >> >> Generated patches split: >> >> misc >> hw/misc/ivshmem.c >> hw/misc/tmp105.c >> hw/misc/tmp421.c >> s390x >> hw/intc/s390_flic_kvm.c >> hw/s390x/3270-ccw.c >> hw/s390x/css-bridge.c >> hw/s390x/css.c >> hw/s390x/s390-skeys.c >> hw/s390x/s390-virtio-ccw.c >> hw/s390x/sclp.c >> hw/s390x/tod-kvm.c >> hw/vfio/ccw.c >> target/s390x/cpu.c >> tcg >> exec.c >> hw/arm/armv7m.c >> hw/arm/smmu-common.c >> hw/arm/smmuv3.c >> hw/cpu/a15mpcore.c >> hw/cpu/a9mpcore.c >> hw/cpu/arm11mpcore.c >> hw/i386/pc.c >> hw/intc/nios2_iic.c >> hw/mips/cps.c >> hw/riscv/riscv_hart.c >> hw/riscv/sifive_e.c >> hw/riscv/sifive_u.c >> hw/sd/milkymist-memcard.c >> target/alpha/cpu.c >> target/arm/cpu.c >> target/arm/cpu64.c >> target/cris/cpu.c >> target/hppa/cpu.c >> target/i386/cpu.c >> target/lm32/cpu.c >> target/m68k/cpu.c >> target/microblaze/cpu.c >> target/mips/cpu.c >> target/moxie/cpu.c >> target/nios2/cpu.c >> target/openrisc/cpu.c >> target/ppc/compat.c >> target/ppc/translate_init.inc.c >> target/riscv/cpu.c >> target/sh4/cpu.c >> target/sparc/cpu.c >> target/tricore/cpu.c >> target/unicore32/cpu.c >> target/xtensa/cpu.c >> kvm >> target/ppc/kvm.c >> target/s390x/cpu_models.c >> xen >> hw/block/dataplane/xen-block.c >> hw/block/xen-block.c >> hw/xen/xen-backend.c >> hw/xen/xen-bus.c >> hw/xen/xen-host-pci-device.c >> hw/xen/xen_pt.c >> hw/xen/xen_pt_config_init.c >> Hosts >> qga/commands-win32.c >> util/oslib-posix.c >> ARM Machines >> hw/arm/allwinner-a10.c >> hw/arm/aspeed_soc.c >> hw/arm/bcm2835_peripherals.c >> hw/arm/bcm2836.c >> hw/arm/digic.c >> hw/arm/fsl-imx25.c >> hw/arm/fsl-imx31.c >> hw/arm/fsl-imx6.c >> hw/arm/integratorcp.c >> hw/arm/msf2-soc.c >> hw/arm/nrf51_soc.c >> hw/arm/stm32f205_soc.c >> hw/arm/virt.c >> hw/arm/xlnx-versal-virt.c >> hw/arm/xlnx-zynqmp.c >> hw/cpu/realview_mpcore.c >>
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
12.11.2019 16:46, Cornelia Huck wrote: > On Fri, 8 Nov 2019 22:57:25 +0400 > Marc-André Lureau wrote: > >> Hi >> >> On Fri, Nov 8, 2019 at 7:31 PM Vladimir Sementsov-Ogievskiy >> wrote: >>> >>> Finally, what is the plan? >>> >>> Markus what do you think? >>> >>> Now a lot of patches are reviewed, but a lot of are not. >>> >>> Is there any hope that all patches will be reviewed? Should I resend the >>> whole series, or may be reduce it to reviewed subsystems only? >> >> I don't think we have well established rules for whole-tree cleanups >> like this. In the past, several cleanup series got lost. > > Yes, it is always problematic if a series touches a lot of different > subsystems. > >> >> It will take ages to get every subsystem maintainer to review the >> patches. Most likely, since they are quite systematic, there isn't >> much to say and it is easy to miss something that has some hidden >> ramifications. Perhaps whole-tree cleanups should require at least 2 >> reviewers to bypass the subsytem maintainer review? But my past >> experience with this kind of exercice doesn't encourage me, and >> probably I am not the only one. > > It's not just the reviews; it's easy to miss compile problems on less > mainstream architectures (and even easier to miss functional problems > there, although they are probably less likely with automated rework.) > CI can probably help, but that's something for the future. > > Anyway, I've now gotten around to that series; spotted one problem in > s390x code, I think. > > One thing that's helpful for such a large series is a git branch that > makes it easy to give the series a quick go. (You can use patchew, but > it takes time before it gets all mails, so just pushing it somewhere > and letting people know is a good idea anyway.) > Thanks for review! The series are posted here: https://src.openvz.org/users/vsementsov/repos/qemu/browse https://src.openvz.org/scm/~vsementsov/qemu.git #tag up-auto-local-err-v5 -- Best regards, Vladimir ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
On Fri, 8 Nov 2019 22:57:25 +0400 Marc-André Lureau wrote: > Hi > > On Fri, Nov 8, 2019 at 7:31 PM Vladimir Sementsov-Ogievskiy > wrote: > > > > Finally, what is the plan? > > > > Markus what do you think? > > > > Now a lot of patches are reviewed, but a lot of are not. > > > > Is there any hope that all patches will be reviewed? Should I resend the > > whole series, or may be reduce it to reviewed subsystems only? > > I don't think we have well established rules for whole-tree cleanups > like this. In the past, several cleanup series got lost. Yes, it is always problematic if a series touches a lot of different subsystems. > > It will take ages to get every subsystem maintainer to review the > patches. Most likely, since they are quite systematic, there isn't > much to say and it is easy to miss something that has some hidden > ramifications. Perhaps whole-tree cleanups should require at least 2 > reviewers to bypass the subsytem maintainer review? But my past > experience with this kind of exercice doesn't encourage me, and > probably I am not the only one. It's not just the reviews; it's easy to miss compile problems on less mainstream architectures (and even easier to miss functional problems there, although they are probably less likely with automated rework.) CI can probably help, but that's something for the future. Anyway, I've now gotten around to that series; spotted one problem in s390x code, I think. One thing that's helpful for such a large series is a git branch that makes it easy to give the series a quick go. (You can use patchew, but it takes time before it gets all mails, so just pushing it somewhere and letting people know is a good idea anyway.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
Hi On Fri, Nov 8, 2019 at 7:31 PM Vladimir Sementsov-Ogievskiy wrote: > > Finally, what is the plan? > > Markus what do you think? > > Now a lot of patches are reviewed, but a lot of are not. > > Is there any hope that all patches will be reviewed? Should I resend the > whole series, or may be reduce it to reviewed subsystems only? I don't think we have well established rules for whole-tree cleanups like this. In the past, several cleanup series got lost. It will take ages to get every subsystem maintainer to review the patches. Most likely, since they are quite systematic, there isn't much to say and it is easy to miss something that has some hidden ramifications. Perhaps whole-tree cleanups should require at least 2 reviewers to bypass the subsytem maintainer review? But my past experience with this kind of exercice doesn't encourage me, and probably I am not the only one. > > 11.10.2019 19:03, Vladimir Sementsov-Ogievskiy wrote: > > 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. > > > > 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 too > > much with it > > - coccinelle: add support of error_propagate_prepend > > > > 27-126: generated patches > > > > > > > > Here is a proposal of auto propagation for local_err, to not call > > error_propagate on every exit point, when we deal with local_err. > > > > There are also two issues with errp: > > > > 1. error_fatal & error_append_hint/error_prepend: user can't see this > > additional info, because exit() happens in error_setg earlier than info > > is added. [Reported by Greg Kurz] > > > > 2. error_abort & error_propagate: when we wrap > > error_abort by local_err+error_propagate, resulting coredump will > > refer to error_propagate and not to the place where error happened. > > (the macro itself don't fix the issue, but it allows to [3.] drop all > > local_err+error_propagate pattern, which will definitely fix the issue) > > [Reported by Kevin Wolf] > > > > > > > > Generated patches split: > > > > misc > > hw/misc/ivshmem.c > > hw/misc/tmp105.c > > hw/misc/tmp421.c > > s390x > > hw/intc/s390_flic_kvm.c > > hw/s390x/3270-ccw.c > > hw/s390x/css-bridge.c > > hw/s390x/css.c > > hw/s390x/s390-skeys.c > > hw/s390x/s390-virtio-ccw.c > > hw/s390x/sclp.c > > hw/s390x/tod-kvm.c > > hw/vfio/ccw.c > > target/s390x/cpu.c > > tcg > > exec.c > > hw/arm/armv7m.c > > hw/arm/smmu-common.c > > hw/arm/smmuv3.c > > hw/cpu/a15mpcore.c > > hw/cpu/a9mpcore.c > > hw/cpu/arm11mpcore.c > > hw/i386/pc.c > > hw/intc/nios2_iic.c > > hw/mips/cps.c > > hw/riscv/riscv_hart.c > > hw/riscv/sifive_e.c > > hw/riscv/sifive_u.c > > hw/sd/milkymist-memcard.c > > target/alpha/cpu.c > > target/arm/cpu.c > > target/arm/cpu64.c > > target/cris/cpu.c > > target/hppa/cpu.c > > target/i386/cpu.c > > target/lm32/cpu.c > > target/m68k/cpu.c > > target/microblaze/cpu.c > > target/mips/cpu.c > > target/moxie/cpu.c > > target/nios2/cpu.c > > target/openrisc/cpu.c > > target/ppc/compat.c > > target/ppc/translate_init.inc.c > > target/riscv/cpu.c > > target/sh4/cpu.c > > target/sparc/cpu.c > > target/tricore/cpu.c > > target/unicore32/cpu.c > > target/xtensa/cpu.c > > kvm > > target/ppc/kvm.c > > target/s390x/cpu_models.c > > xen > > hw/block/dataplane/xen-block.c > > hw/block/xen-block.c > > hw/xen/xen-backend.c > > hw/xen/xen-bus.c > > hw/xen/xen-host-pci-device.c > > hw/xen/xen_pt.c > > hw/xen/xen_pt_config_init.c > > Hosts > > qga/commands-win32.c > > util/oslib-posix.c > > ARM Machines > > hw/arm/allwinner-a10.c > > hw/arm/aspeed_soc.c > > hw/arm/bcm2835_peripherals.c > > hw/arm/bcm2836.c > > hw/arm/digic.c > > hw/arm/fsl-imx25.c > > hw/arm/fsl-imx31.c > > hw/arm/fsl-imx6.c > > hw/arm/integratorcp.c > > hw/arm/msf2-soc.c > > hw/arm/nrf51_soc.c > > hw/arm/stm32f205_soc.c > > hw/arm/virt.c > > hw/arm/xlnx-versal-virt.c > > hw/arm/xlnx-zynqmp.c > > hw/cpu/realview_mpcore.c > > hw/display/bcm2835_fb.c > > hw/dma/bcm2835_dma.c > > hw/dma/xilinx_axidma.c > > hw/gpio/aspeed_gpio.c > > hw/gpio/bcm2835_gpio.c > > hw/intc/arm_gic.c > > hw/intc/arm_gic_kvm.c > > hw/intc/arm_gicv3.c > >
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
Finally, what is the plan? Markus what do you think? Now a lot of patches are reviewed, but a lot of are not. Is there any hope that all patches will be reviewed? Should I resend the whole series, or may be reduce it to reviewed subsystems only? 11.10.2019 19:03, Vladimir Sementsov-Ogievskiy wrote: > 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. > > 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 too > much with it > - coccinelle: add support of error_propagate_prepend > > 27-126: generated patches > > > > Here is a proposal of auto propagation for local_err, to not call > error_propagate on every exit point, when we deal with local_err. > > There are also two issues with errp: > > 1. error_fatal & error_append_hint/error_prepend: user can't see this > additional info, because exit() happens in error_setg earlier than info > is added. [Reported by Greg Kurz] > > 2. error_abort & error_propagate: when we wrap > error_abort by local_err+error_propagate, resulting coredump will > refer to error_propagate and not to the place where error happened. > (the macro itself don't fix the issue, but it allows to [3.] drop all > local_err+error_propagate pattern, which will definitely fix the issue) > [Reported by Kevin Wolf] > > > > Generated patches split: > > misc > hw/misc/ivshmem.c > hw/misc/tmp105.c > hw/misc/tmp421.c > s390x > hw/intc/s390_flic_kvm.c > hw/s390x/3270-ccw.c > hw/s390x/css-bridge.c > hw/s390x/css.c > hw/s390x/s390-skeys.c > hw/s390x/s390-virtio-ccw.c > hw/s390x/sclp.c > hw/s390x/tod-kvm.c > hw/vfio/ccw.c > target/s390x/cpu.c > tcg > exec.c > hw/arm/armv7m.c > hw/arm/smmu-common.c > hw/arm/smmuv3.c > hw/cpu/a15mpcore.c > hw/cpu/a9mpcore.c > hw/cpu/arm11mpcore.c > hw/i386/pc.c > hw/intc/nios2_iic.c > hw/mips/cps.c > hw/riscv/riscv_hart.c > hw/riscv/sifive_e.c > hw/riscv/sifive_u.c > hw/sd/milkymist-memcard.c > target/alpha/cpu.c > target/arm/cpu.c > target/arm/cpu64.c > target/cris/cpu.c > target/hppa/cpu.c > target/i386/cpu.c > target/lm32/cpu.c > target/m68k/cpu.c > target/microblaze/cpu.c > target/mips/cpu.c > target/moxie/cpu.c > target/nios2/cpu.c > target/openrisc/cpu.c > target/ppc/compat.c > target/ppc/translate_init.inc.c > target/riscv/cpu.c > target/sh4/cpu.c > target/sparc/cpu.c > target/tricore/cpu.c > target/unicore32/cpu.c > target/xtensa/cpu.c > kvm > target/ppc/kvm.c > target/s390x/cpu_models.c > xen > hw/block/dataplane/xen-block.c > hw/block/xen-block.c > hw/xen/xen-backend.c > hw/xen/xen-bus.c > hw/xen/xen-host-pci-device.c > hw/xen/xen_pt.c > hw/xen/xen_pt_config_init.c > Hosts > qga/commands-win32.c > util/oslib-posix.c > ARM Machines > hw/arm/allwinner-a10.c > hw/arm/aspeed_soc.c > hw/arm/bcm2835_peripherals.c > hw/arm/bcm2836.c > hw/arm/digic.c > hw/arm/fsl-imx25.c > hw/arm/fsl-imx31.c > hw/arm/fsl-imx6.c > hw/arm/integratorcp.c > hw/arm/msf2-soc.c > hw/arm/nrf51_soc.c > hw/arm/stm32f205_soc.c > hw/arm/virt.c > hw/arm/xlnx-versal-virt.c > hw/arm/xlnx-zynqmp.c > hw/cpu/realview_mpcore.c > hw/display/bcm2835_fb.c > hw/dma/bcm2835_dma.c > hw/dma/xilinx_axidma.c > hw/gpio/aspeed_gpio.c > hw/gpio/bcm2835_gpio.c > hw/intc/arm_gic.c > hw/intc/arm_gic_kvm.c > hw/intc/arm_gicv3.c > hw/intc/arm_gicv3_its_kvm.c > hw/intc/arm_gicv3_kvm.c > hw/intc/armv7m_nvic.c > hw/intc/realview_gic.c > hw/microblaze/xlnx-zynqmp-pmu.c > hw/misc/bcm2835_mbox.c > hw/misc/bcm2835_property.c > hw/misc/msf2-sysreg.c > hw/net/xilinx_axienet.c > hw/nvram/nrf51_nvm.c > hw/timer/aspeed_timer.c > hw/watchdog/wdt_aspeed.c > MIPS Machines > hw/core/loader-fit.c > PowerPC Machines > hw/intc/pnv_xive.c > hw/intc/xics.c > hw/intc/xics_kvm.c > hw/intc/xics_pnv.c > hw/intc/xics_spapr.c > hw/isa/pc87312.c > hw/misc/macio/macio.c > hw/ppc/e500.c > hw/ppc/mac_newworld.c > hw/ppc/pnv.c > hw/ppc/pnv_core.c > hw/ppc/pnv_homer.c > hw/ppc/pnv_lpc.c > hw/ppc/pnv_occ.c > hw/ppc/pnv_psi.c > hw/ppc/spapr.c > hw/ppc/spapr_caps.c > hw/ppc/spapr_cpu_core.c > hw/ppc/spapr_drc.c > hw/ppc/spapr_irq.c >
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
12.10.2019 5:10, no-re...@patchew.org wrote: > Patchew URL: > https://patchew.org/QEMU/20191011160552.22907-1-vsement...@virtuozzo.com/ > > > > Hi, > > This series failed the docker-quick@centos7 build test. Please find the > testing commands and > their output below. If you have Docker installed, you can probably reproduce > it > locally. > > === TEST SCRIPT BEGIN === > #!/bin/bash > make docker-image-centos7 V=1 NETWORK=1 > time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 > === TEST SCRIPT END === > >TESTiotest-qcow2: 013 >TESTcheck-unit: tests/test-block-iothread >TESTcheck-unit: tests/test-image-locking > warning: Failed to get shared "consistent read" lock > Is another process using the image [/tmp/qtest.O66l3t]? > warning: Failed to get shared "consistent read" lock > Is another process using the image [/tmp/qtest.G0M9V8]? >TESTcheck-unit: tests/test-x86-cpuid >TESTcheck-unit: tests/test-xbzrle > --- >TESTiotest-qcow2: 267 > Failures: 054 > Failed 1 of 108 iotests > make: *** [check-tests/check-block.sh] Error 1 > make: *** Waiting for unfinished jobs >TESTcheck-qtest-aarch64: tests/qos-test > Traceback (most recent call last): > --- > raise CalledProcessError(retcode, cmd) > subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', > '--label', 'com.qemu.instance.uuid=2c55fb61a63a409382f2b3a99fca93d9', '-u', > '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', > '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', > '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', > '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', > '/var/tmp/patchew-tester-tmp-usvi8fob/src/docker-src.2019-10-11-22.00.10.1933:/var/tmp/qemu:z,ro', > 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit > status 2. > filter=--filter=label=com.qemu.instance.uuid=2c55fb61a63a409382f2b3a99fca93d9 > make[1]: *** [docker-run] Error 1 > make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-usvi8fob/src' > make: *** [docker-run-test-quick@centos7] Error 2 Something strange. Who knows, what is it? > > real10m33.714s > user0m8.360s > > > The full log is available at > http://patchew.org/logs/20191011160552.22907-1-vsement...@virtuozzo.com/testing.docker-quick@centos7/?type=message. "" Not Found The requested resource was not found on this server. "" > --- > Email generated automatically by Patchew [https://patchew.org/]. > Please send your feedback to patchew-de...@redhat.com > -- Best regards, Vladimir ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
12.10.2019 5:52, no-re...@patchew.org wrote: > Patchew URL: > https://patchew.org/QEMU/20191011160552.22907-1-vsement...@virtuozzo.com/ > > > > Hi, > > This series seems to have some coding style problems. See output below for > more information: > > Subject: [RFC v5 000/126] error: auto propagated local_err > Type: series > Message-id: 20191011160552.22907-1-vsement...@virtuozzo.com > > === TEST SCRIPT BEGIN === > #!/bin/bash > git rev-parse base > /dev/null || exit 0 > git config --local diff.renamelimit 0 > git config --local diff.renames True > git config --local diff.algorithm histogram > ./scripts/checkpatch.pl --mailback base.. > === TEST SCRIPT END === > > Switched to a new branch 'test' > 319b206 util/qemu-config.c: introduce ERRP_AUTO_PROPAGATE > 3ee6567 tests/test-image-locking.c: introduce ERRP_AUTO_PROPAGATE > 2e4f371 target/tilegx/cpu.c: introduce ERRP_AUTO_PROPAGATE > 5f766d7 memory_mapping.c: introduce ERRP_AUTO_PROPAGATE > 8969c6f iothread.c: introduce ERRP_AUTO_PROPAGATE > 1534a92 hw/sd/ssi-sd.c: introduce ERRP_AUTO_PROPAGATE > b5b1e0a hw/cpu/core.c: introduce ERRP_AUTO_PROPAGATE > dd3f310 hw/core/bus.c: introduce ERRP_AUTO_PROPAGATE > 21ee5f8 PVRDMA: introduce ERRP_AUTO_PROPAGATE > 84365ab Replication: introduce ERRP_AUTO_PROPAGATE > 225bbc5 vvfat: introduce ERRP_AUTO_PROPAGATE > 2da58d6 vpc: introduce ERRP_AUTO_PROPAGATE > e7fb0b9 blkdebug: introduce ERRP_AUTO_PROPAGATE > 39d367e qcow: introduce ERRP_AUTO_PROPAGATE > 1b7546c qcow2: introduce ERRP_AUTO_PROPAGATE > c0352a1 raw: introduce ERRP_AUTO_PROPAGATE > 612aebf qed: introduce ERRP_AUTO_PROPAGATE > 155f6ea parallels: introduce ERRP_AUTO_PROPAGATE > 5d3c3fd blkverify: introduce ERRP_AUTO_PROPAGATE > 36132e6 blklogwrites: introduce ERRP_AUTO_PROPAGATE > 785cfb4 Quorum: introduce ERRP_AUTO_PROPAGATE > 5acba63 Bootdevice: introduce ERRP_AUTO_PROPAGATE > 0e0d3fb NVMe Block Driver: introduce ERRP_AUTO_PROPAGATE > 1cf6911 GLUSTER: introduce ERRP_AUTO_PROPAGATE > cb4c8f7 CURL: introduce ERRP_AUTO_PROPAGATE > 4e32493 SSH: introduce ERRP_AUTO_PROPAGATE > abbecd4 NFS: introduce ERRP_AUTO_PROPAGATE > f4f937d nbd: introduce ERRP_AUTO_PROPAGATE > 7b638b3 iSCSI: introduce ERRP_AUTO_PROPAGATE > 4727ffc VDI: introduce ERRP_AUTO_PROPAGATE > 2c03145 VHDX: introduce ERRP_AUTO_PROPAGATE > 7916a87 Sheepdog: introduce ERRP_AUTO_PROPAGATE > db15fdd RBD: introduce ERRP_AUTO_PROPAGATE > 05ea2cf VMDK: introduce ERRP_AUTO_PROPAGATE > ff11144 Record/replay: introduce ERRP_AUTO_PROPAGATE > a95fab2 colo: introduce ERRP_AUTO_PROPAGATE > be71202 Sockets: introduce ERRP_AUTO_PROPAGATE > 69a59b0 I/O Channels: introduce ERRP_AUTO_PROPAGATE > e4f56f3 Cryptography: introduce ERRP_AUTO_PROPAGATE > 4f5f412 Migration: introduce ERRP_AUTO_PROPAGATE > 985da1a TPM: introduce ERRP_AUTO_PROPAGATE > b19cdab Tracing: introduce ERRP_AUTO_PROPAGATE > 3113fc7 SLIRP: introduce ERRP_AUTO_PROPAGATE > 51e2f48 QMP: introduce ERRP_AUTO_PROPAGATE > 1c0c827 QOM: introduce ERRP_AUTO_PROPAGATE > fc0eec4 qga: introduce ERRP_AUTO_PROPAGATE > af16041 QAPI: introduce ERRP_AUTO_PROPAGATE > 21ed21e cryptodev: introduce ERRP_AUTO_PROPAGATE > 7ab6e12 hostmem: introduce ERRP_AUTO_PROPAGATE > 994c02c net: introduce ERRP_AUTO_PROPAGATE > 26fe9a4 Human Monitor (HMP): introduce ERRP_AUTO_PROPAGATE > 82b7f8b Main loop: introduce ERRP_AUTO_PROPAGATE > 863100d Graphics: introduce ERRP_AUTO_PROPAGATE > 45a8d41 SPICE: introduce ERRP_AUTO_PROPAGATE > 6d967ec Memory API: introduce ERRP_AUTO_PROPAGATE > 5645325 Dump: introduce ERRP_AUTO_PROPAGATE > 6d795b4 cmdline: introduce ERRP_AUTO_PROPAGATE > 5fceaa3 chardev: introduce ERRP_AUTO_PROPAGATE > d551bda scsi: introduce ERRP_AUTO_PROPAGATE > cc3d83e block: introduce ERRP_AUTO_PROPAGATE > 75b948b Audio: introduce ERRP_AUTO_PROPAGATE > c3fee2f XIVE: introduce ERRP_AUTO_PROPAGATE > 42ba3e1 fw_cfg: introduce ERRP_AUTO_PROPAGATE > 90c4efa virtio-gpu: introduce ERRP_AUTO_PROPAGATE > 4db3f47 eepro100: introduce ERRP_AUTO_PROPAGATE > d7634f4 NVDIMM: introduce ERRP_AUTO_PROPAGATE > 706ee21 megasas: introduce ERRP_AUTO_PROPAGATE > a037a5c virtio-rng: introduce ERRP_AUTO_PROPAGATE > dcf1769 virtio-serial: introduce ERRP_AUTO_PROPAGATE > 77d26d1 virtio-input: introduce ERRP_AUTO_PROPAGATE > 7f62cb1 virtio-ccw: introduce ERRP_AUTO_PROPAGATE > 2bdd860 virtio-blk: introduce ERRP_AUTO_PROPAGATE > 026260e virtio-9p: introduce ERRP_AUTO_PROPAGATE > 191c845 virtio: introduce ERRP_AUTO_PROPAGATE > 24510de vhost: introduce ERRP_AUTO_PROPAGATE > e8a1779 vfio-ccw: introduce ERRP_AUTO_PROPAGATE > 00baaa3 VFIO: introduce ERRP_AUTO_PROPAGATE > 361c201 USB (serial adapter): introduce ERRP_AUTO_PROPAGATE > 0f70e97 USB: introduce ERRP_AUTO_PROPAGATE > 9548378 SD (Secure Card): introduce ERRP_AUTO_PROPAGATE > 90b472d SCSI: introduce ERRP_AUTO_PROPAGATE > 312220a pflash: introduce ERRP_AUTO_PROPAGATE > 47a7bb5 Network devices: introduce ERRP_AUTO_PROPAGATE > bf2e1ef ACPI/SMBIOS: introduce ERRP_AUTO_PROPAGATE > 98f6d04 PCI: introduce ERRP_AUTO_PROPAGATE > e3e14fe IPack: introduce
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
11.10.2019 20:02, Eric Blake wrote: > On 10/11/19 11:03 AM, Vladimir Sementsov-Ogievskiy wrote: >> 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. > > Is there a repo containing these patches, to make it easier to play with them > locally without having to 'git am' the entire 126 messages? Done: https://src.openvz.org/users/vsementsov/repos/qemu/browse https://src.openvz.org/scm/~vsementsov/qemu.git #tag up-auto-local-err-v5 > > >> util/qemu-sockets.c | 31 +-- >> vl.c | 14 +- >> python/commit-per-subsystem.py | 204 ++ >> scripts/coccinelle/auto-propagated-errp.cocci | 118 >> 341 files changed, 3851 insertions(+), 4455 deletions(-) >> create mode 100755 python/commit-per-subsystem.py >> create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci > > So, whether or not we take commit-per-subsystem.py, the overall series > appears to be a nice reduction in lines of code. > -- Best regards, Vladimir ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err
On 10/11/19 11:03 AM, Vladimir Sementsov-Ogievskiy wrote: 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. Is there a repo containing these patches, to make it easier to play with them locally without having to 'git am' the entire 126 messages? util/qemu-sockets.c | 31 +-- vl.c | 14 +- python/commit-per-subsystem.py| 204 ++ scripts/coccinelle/auto-propagated-errp.cocci | 118 341 files changed, 3851 insertions(+), 4455 deletions(-) create mode 100755 python/commit-per-subsystem.py create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci So, whether or not we take commit-per-subsystem.py, the overall series appears to be a nice reduction in lines of code. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
