On Wed, Dec 22 2021, Jonathan Tan wrote: >> A small set of fixes to usage.[ch]'s API use that will go towards >> enabling nicer things down the road. See [1] for the v1 summary >> >> I believe this should address all the feedback Junio had on the >> v1. >> >> Aside from the substantially rewritten 6/6 and much simplified 4/6 the >> end-state is almost the same, but things are better split up, >> explained etc. now. >> >> 1. https://lore.kernel.org/git/cover-0.4-00000000000-20211206T165221Z-avarab@xxxxxxxxx/ > > I haven't looked at this round of patches yet, but for the convenience > of reviewers, it would have been great if you linked to a prior > discussion [1], FWIW this is (indirectly) linked-to upthread. I linked to this RFC series which this is peeled from: https://lore.kernel.org/git/RFC-cover-00.21-00000000000-20211115T220831Z-avarab@xxxxxxxxx/ Which in turn links to the earlier series you commented on that die_message() is peeled off from: https://lore.kernel.org/git/cover-v3-0.6-00000000000-20211022T175227Z-avarab@xxxxxxxxx/ > including an email from me with comments that (as far as > I know) haven't been addressed [2]. Is there anything to address in the context of this current series? I.e. you're commenting on leak detection, which isn't at all the goal of this series. I.e. I had these die_message() changes that I worked into that series, but there didn't seem to be any interest in code changes that "solved" issues of SANITIZE=leak interaction with various non-CI compiler versions/flags, so I didn't think it was worth pursuing. But as this series shows die_message() is also something we can use in other contexts. > [1] https://lore.kernel.org/git/patch-1.1-5a47bf2e9c9-20211021T114223Z-avarab@xxxxxxxxx/ > [2] https://lore.kernel.org/git/20211027215053.2257548-1-jonathantanmy@xxxxxxxxxx/
