>> See also: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.18-rc7#n94 > > "Describe your changes in imperative mood" > > I guess I can try rewording this, …
I became curious once more how another improved change descrition can look like. >>> +virtual patch >> >> Will additional operation modes become relevant after clarification of >> implementation details? > > I am not interested in other modes; if people want to contribute them, > they are welcome. :) Will development interests eventually grow accordingly? >> … >>> +def alloc_array(name): >>> + func = "FAILED_RENAME" >>> + if name == "kmalloc_array": >>> + func = "kmalloc_objs" >> … >> >> * I suggest to avoid duplicate variable assignments. >> >> * How do you think about to collaborate with the Python data structure >> “dictionary”? > > I wanted the stderr warning when there was no match, but to return > "FAILED_RENAME" in such a case. Such a data processing result can be achieved also by a more appropriate algorithm, can't it? > Using a dictionary was basically the > same length as the elif stack. If you have an alternative, I'm happy to > replace it with what you come up with. Is there a need for further case distinctions? >> … >>> +type TYPE; >>> +TYPE *P; >>> +TYPE INST; >>> +expression VAR; >>> +expression GFP; >> … >> >> Such repetition of SmPL key words can eventually be also avoided. > > That is true, but I like having them separated -- I find it more > readable that way. Under which circumstances would you become used also to more succinct SmPL code? Regards, Markus
