>> I am curious if a second approach will become acceptable in the near future. > > I don't know what you were asking. I am trying to clarify the suggested software evolution again. > I was merely point out that the wording was factually incorrect > in all of the patches, Thanks for this information. > and I didn't feel like replying five times to point out the same mistake. This is fine. >>> since reading from /proc isn't done in a tight loop, and even if it were, >>> the use of vsprintf is the tiniest part of the overhead. >> >> Thanks for your software development opinion. > > It's a lot more than just an opinion. I challenge you to demonstrate > how much savings it would take. Try learning how to use another tool > --- say, perf. Measure how many clock cycles it takes to read from a > proc file that uses seq_printf(). Then measure how many clock cycles > it takes to read from a proc file that uses seq_puts(). Try doing the > experiment 3-5 times each way, to see if the difference is within > measurement error, and then figure out what percentage of the total > CPU time you have saved. Are there any more software developers interested in such system performance analyses? > If this sort of thing appeals to you, you might want to consider a > more productive line of work. For example, you could do scalability > measurements. Run various benchmarks with lockdep enabled, and > measure the average and max hold time on various locks. Now see if > you can reduce the max hold time on those locks. You may find that > you can improve performance for real work loads by orders of magnitude > more than you can by sending the sorts of patches you've sent up until now. Thanks for your hints around other software development areas. > You'd also development more marketable kernel skills, if that has been > your goal by spamming the list with hundreds and thousands of mostly > pointless patches. You might categorise my update suggestions with a low value so far. > Note that if a hiring manager were to talk to developers and get > their opinion of the sorts of patches you have been sending, trust me, > it would _not_ be positive. There are also some constraints around change resistance involved, aren't there? * Do my suggestions show small improvements for Linux source files? * If you find some of them so awful, why should I attempt to improve any commit messages in another patch series then? > So trying to send more useful patches might be more helpful > if your goal is to try to get gainful employment. Financial incentives would be also nice as you seem to indicate here. Regards, Markus
