>> Will the compilation be a bit quicker when extra data processing >> could be omitted? > > Why would you care more about the time it takes to compile the kernel, > than the time it takes for executing it? I am also interested in the evolution of compilation time frames. > Benchmarks are all about performance of a running kernel, This is generally reasonable. > nobody compares benchmarks of the time it takes to compile it. I guess that the situation can be occasionally different there. > Sure, we like to make the compile times quicker Good to know … > (heck, I wrote "make localmodconfig" for just that purpose), Thanks. > but we never favor compiler time over execution time. I imagine that the speed expectations could be adjusted during software development, couldn't they? > In fact, if we can improve the execution performance by sacrificing compile time, > we are happy to do that. I guess that you would like to consider some constraints there. >>> In fact, we do a lot of tricks to make sure that things work the way >>> we expect it to, because we add broken code that only gets compiled out >>> when gcc optimizes the code the way we expect it to be, >>> and the kernel build will break otherwise. >> >> * Can this goal be also achieved without the addition of “broken code”? > > No. Will any other contributors take another look? >> * How do you think about to improve the error handling there? > > It works just fine as is. I hope that further software improvements can be achieved also for this use case. > Errors that can be detected at build time are 100 times better > than detecting them at execution time. I agree to such a general view. Will an other (or no) error message be more appropriate? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
