Re: [PATCH v3 0/5] config-parse: create config parsing library

From: Jonathan Tan <jonathantanmy@google.com>
Date: Oct 24, 2023, 22:50 UTC
Message-ID: <20231024225005.1191555-1-jonathantanmy@google.com>
In-Reply-To: <ZTbK3QTJYXxYj/M6@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

Show 13 quoted lines

> But I am not sure that I agree that this series is moving us in the
> right direction necessarily. Or at least I am not convinced that
> shipping the intermediate state is worth doing before we have callers
> that could drop '#include "config.h"' for just the parser.
> 
> This feels like churn that does not yield a tangible pay-off, at least
> in the sense that the refactoring and code movement delivers us
> something that we can substantively use today.
> 
> I dunno.
> 
> Thanks,
> Taylor

Thanks for calling this out. We do want our changes to be good for both the libification and the non-libification cases as much as possible. As it is, I do agree that since we won't have callers that can use the new parser header (I think the likeliest cause of having such a caller is if we have a "interpret-config" command, like "interpret-trailers"), we probably shouldn't merge this (at least, the last 2 patches).

I think patches 1-3 are still usable (they make some internals of config parsing less confusing) but I'm also OK if we hold off on them until we find a compelling use case that motivates refactoring on the config parser.