Elijah Newren <newren@xxxxxxxxx> writes: > So, I'd say it is more about programming errors, in particular ones > where people modify the code to make process_entry() leave more cases > unprocessed than what is currently possible without also making the > necessary modifications to process_df_entry(). Yeah. But they do not need to touch process_df_entry(). I actually was hoping that my weatherbaloon patch will illustrate that a new special case these people may make to process_entry() to leave other cases unprocessed do _NOT_ have to be handled by process_df_entry(). The "if" statement in process_df_entry() would check if the entry is something the function is ready to resolve, and otherwise punts. A new exception they add to process_entry() can introduce a separate phase (just like process_df_entry() is not done in parallel with other kinds of entries inside the process_entry() but as a separate post-processing phase) between the loop that calls process_df_entry() and the loop that checks if there is a remaining entry. And it probably should, as such a new exception may not have anything to do with "df", and adding such a logic to process_df_entry() would be wrong ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html