Re: [Libguestfs] [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe()

Sorry about replying for the second time. After having slept on it (not much, but some), some thoughts are emerging / being distilled about my own attitude. On 2/21/23 19:04, Daniel P. Berrangé wrote: The attitude you describe above and my attitude are largely driven by the same goal: target development as narrowly as possible. Portability is essential in both cases; the big difference is in the workflow chosen for achieving portability. Approach #1: A number of OSes and a number of tools (compilers etc) are hand-picked, based on "practical" factors. This set of components taken as a whole does not have uniform, central documentation. Therefore, development is driven by (a) continuously consulting multiple -- often conflicting -- sets of documentation, and by (b) trial-and-error. By "trial-and-error" I mean that a "CI pass" is taken as strong evidence of absence of bugs, including portability bugs. The workflow relies heavily on CI to root out portability bugs. The advantage of this approach is that it deduces -- with documentation reconciliation, trial-and-error, and compiler / OS / libc source code investigation -- such a "common denominator" that is fairly likely the *greatest* common denominator. Therefore less/simpler code has to be written and maintained for feature and bugfix delivery. The disadvantage is that there is no single source of truth; the workflow is centered on reconciling incomplete and/or conflicting documentation sets, and "happens to work in CI" is taken as the final argument. CI is costly in computing time (energy), developer time (waiting, bad presentation of results), and money (minutes are expensive), and locally testing all targeted platforms is a huge chore. CI development/management in itself consumes immense human effort. Approach #2: target a published technical standard, as a single source of truth. Still employ CI, but not as a guiding tool, more like "just in case". CI failures originating from portability issues are not expected by general. CI success is not taken as the primary evidence of lack of portability bugs. The advantage of this approach is that developers can focus on a single source of truth, for driving development -- POSIX. Patching up portability problems may occasionally be necessary, but that should be the exception. The disadvantage of this approach is that POSIX, while arguably a common denominator, is almost certainly not the *greatest* common denominator. Therefore, more code needs to be written and maintained, plus recent developments that "eventually" appear in all of the targeted platforms / tools, are not consumable until they become centrally standardized. So, here's the thing: at a personal level, I can entirely identify with approach #2, and I'm unable to identify with approach #1, as the development workflow that I am supposed to follow and practice. To me, being torn to pieces between 3-4 conflicting documentation sets, and writing code such that the *primary metric* be "let me see if this passes CI -- let me throw code at the wall and see what sticks" is unbearable. Having to submit several tweaks in succession and waiting tens of minutes for CI to finish every time, rules out software development as a profession for me. (CI remains relevant anyway, but not for dictating or driving portability decisions.) Having to test out interfaces manually that are supposed to be standard, for determining and exploiting their *accidental* greatest common denominator, again rules out software development for me as a profession. Such work *is* valuable, but it's called standardization / standards development, not software development. I don't mind participating in standards development, but the *output* of that activity needs to be a *central formal standard* that programmers can rely upon in the future, not some implicit understanding that gets encoded in / dispersed over a bunch of disparate applications and libraries -- such as "we can call execvp() here because our particular fork() version lets us" -- that merely happen to target the same arbitrary set of platforms. QEMU actually gets this *quite* right, with "devel/style.rst". It still doesn't say anything about fork()/execvp() though, for example. On the same note, I honestly think that the conflict between the linux manual pages and the GNU manual, regarding the child process restrictions, is *unforgivable*. Note that I'm not trying to assert an objective truth here. All I'm saying is I'm personally incompatible with approach#1. To me, *how* I work is generally more important than *what* I achieve for users. Under that umbrella, the justification for introducing our own async-signal-safe execvpe in this patch is simply the fact that the official documentations (plural) available on Linux are *inconsistent* about fork()+execvp(). The fact that it "happens" to work in practice is just happenstance. If you will, call this my denial of practical reality. So: if the libnbd project can tolerate my attitude (approach#2), then I'd like to proceed with this series (full scope), with me addressing the v3 review feedback in v4, and so on. If not, then I'll abandon the series, and try to make myself useful with something else -- where my basic stance, towards whatever documentation I read, need not be *distrust*. Laszlo