>>> Does it improve code? Does it improve anything? >> >> Yes. - I got such an impression. >> >> * Is it more efficient to call the function "seq_printf" for the desired data processing >> for a single character than to pass it to the function "" in a string? >> >> * Will the required data transfer shrink a bit for the affected functions because of >> such a change? >> > Which are questions _you_ should be able to answer. I wonder that the answers are not obvious for you already. Calling the function "seq_putc" will be more efficient than "seq_printf" in this case because of the following reasons. 1. How does the distribution look like for supported processor architectures where the data transfer for bytes (as a function call parameter) is faster than for (string) pointers? 2. Did anybody measure already how many the execution times can vary for these functions? 3. seq_printf() provides more functionality as this kind of programming interface was designed for a bigger purpose. How much do you care for consequences when such general functions are called with input data they were not designed for mainly? 4. The seq_putc() implementation is so simple. http://lxr.free-electrons.com/source/fs/seq_file.c?v=4.8#L657 Where do you get doubts about its efficiency for the data processing of a single character? > It's your patch, after all. Yes. - I published a special update suggestion once again. > Once you do (and prove that the answer is 'yes' to the above two > questions) the patch will be applied. How do you think about to share a bit more from your software development and testing experience? Which call frequencies do you observe for the affected functions? 1. raid1_status 2. raid10_status 3. raid5_status Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
