On 05.12.2019 12:02, Durrant, Paul wrote: >> -----Original Message----- >> From: Xen-devel <xen-devel-boun...@lists.xenproject.org> On Behalf Of Jan >> Beulich >> Sent: 05 December 2019 10:26 >> To: Xia, Hongyan <hongy...@amazon.com> >> Cc: andrew.coop...@citrix.com; xen-devel@lists.xenproject.org; w...@xen.org; >> roger....@citrix.com >> Subject: Re: [Xen-devel] [PATCH v4 6/9] x86/mm: add an end_of_loop label >> in map_pages_to_xen >> >> On 05.12.2019 11:21, Xia, Hongyan wrote: >>>> On 02.10.2019 19:16, Hongyan Xia wrote: >>>>> We will soon need to clean up mappings whenever the out most loop is >>>>> ended. Add a new label and turn relevant continue's into goto's. >>>> >>>> I think already when this still was RFC I did indicate that I'm not >>>> happy about the introduction of these labels (including also patch 8). >>>> I realize it's quite a lot to ask, but both functions would benefit >>> >from splitting up into per-level helper functions, which - afaict - >>>> would avoid the need for such labels, and which would at the same >>>> time likely make it quite a bit easier to extend these to the >>>> 5-level page tables case down the road. >>> >>> A common pattern I have found when mapping PTE pages on-demand (and I >>> think is the exact intention of these labels from Wei, also described >>> in the commit message) is that we often need to do: >>> >>> map some pages - process those pages - error occurs or this iteration >>> of loop can be skipped - _clean up the mappings_ - continue or return >>> >>> As long as cleaning up is required, these labels will likely be needed >>> as the clean-up path before skipping or returning, so I would say we >>> will see such labels even if we split it into helper functions >>> (virt_to_xen_l[123]e() later in the patch series is an example). I see >>> the labels more or less as orthogonal to modularising into helper >>> functions. >> >> I think differently: The fact that labels are needed is because of >> the complexity of the functions. Simpler functions would allow >> goto-free handling of such error conditions (by instead being able >> to use continue, break, or return without making the code less >> readable, often even improving readability). > > And what is wrong with using goto-s? It is a *very* common style of > error handling use widely in e.g. the linux kernel. IMO it often > makes error paths much more obvious and easier to reason about. In > fact I very much dislike returns from the middle of functions as > they can easily lead to avoidance of necessary error cleanup.
Whereas I personally dislike goto-s (and I've been taught so when first learning programming languages). In private code I avoid them by all means. In projects I'm the maintainer for I accept them when the alternative is noticeably more ugly. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
