On Tue, May 4, 2021 at 11:22 AM Michal Suchánek <msuchanek@xxxxxxx> wrote: > > Except it makes answering the question "Is this bug we see on this > ancient system still present in upstream?" needlessly more difficult to > answer. Can you please provide some details? If you are talking about testing a new kernel image in the ancient system "as-is", why wouldn't you build it in a newer system? If you are talking about particular problems about bisecting (kernel, compiler) pairs etc., details would also be welcome. > Sure, throwing out old compiler versions that are known to cause > problems makes sense. Updating to latest just because much less so. I definitely did not argue for "latest compiler" or "updating just because". > One of the selling point of C in general and gcc in particular is > stability. If we need the latest compiler we can as well rewrite the > kernel in Rust which has a required update cycle of a few months. Rust does not have a "required update cycle" and it does not break old code unless really required, just like C and common compilers. Concerning GCC, they patch releases for ~2.5 years, sure, but for many projects that is not nearly enough. So you still need custom support, which is anyway what most people care about. > Because some mainline kernel features rely on bleeding edge tools I end > up building mainline with current tools anyway but if you do not need > BTF or whatever other latest gimmick older toolchains should do. It would be better to hear concrete arguments about why "older toolchains should do", rather than calling things a gimmick. Cheers, Miguel
