On Thu, Oct 13, 2022 at 09:23:36AM -0600, Jason A. Donenfeld wrote: > On Thu, Oct 13, 2022 at 01:59:52PM +0100, Mark Brown wrote: > > The expected users for old toolchains was always users doing something > > like building a newer kernel on an old enterprise distro rather than > > people actually developing anything AIUI. > The thing is, do we really want to be catering to this? In the first > place, enterprise users and enterprise kernels are already doing freaky > things, forked to no end. But moreover, do we actually want to support My understanding with that use case was that it was precisely people who were happy enough with a disro userspace but wanted something more mainline for their kernel for whatever reason but quite often involving not having all the fun enterprise patching. One use case I've heard of is doing semi-embedded stuff where you need kernel support for the hardware but everything exciting in userspace is locally developed software. > people building the kernel with a different compiler than most of us > develop with? In a basic way, that just seems like a recipe for > disaster. Personally I do frequently use my distro compiler FWIW. > It's also easy, nearly trivial, to download toolchains. Arnd provides a > bunch with his crosstool. "Must use a toolchain from your distro" is a > requirement that affects nobody. I wouldn't be so sure about that if you express the requirement as "must have control over and reproducability for the build environment" instead, it's a lot easier to get everything by installing distro packages than to have to introduce custom steps (having packaged versions of things even if not provided by the distro themselves helps here). It's not that it's impossible for people to get things set up but it's definitely a barrier - I know there's a bunch of projects I should look at but don't do anything with precisely because it's too much work to figure out how to install and keep up to date whatever shiny new build dependencies they're requiring without messing up any of the distro provided stuff. Those do tend to be things other than the basic C compiler though. > So I just think we're thinking about this all wrong. It doesn't matter > what's available on the distros. It matters what the most reasonable > compiler to develop with is, first of all. And secondly, it matters that > this compiler is easily available for users to download in a variety of > settings need-be. And I'm pretty sure this latter part is already the > case. There's definitely tarballs for the kernel side stuff which is fine for development use, I'm not aware of packaged versions. There are things like tuxmake which will run the builds in containers which is another approach to the problem, though again that'd require people to control both the tool version and the container versions which might not be much of a win compared to dealing with tarballs. > Plus, as I mentioned earlier, this is already the model we're going > toward by virtue of Rust (and to a small extent, Clang) invading. Yeah, like I say I suspect that the way we handle dependencies for those might change if people were using those things without actively seeking them out. You can flip things around and say that the reason we're happy to upgrade the base requirement for clang is that people using it are actively seeking it out already so there's not the demand for working with older versions. At least for me it also helps that clang provides apt repositories for current versions. Note that I'm not saying we shouldn't upgrade our requirements at all, just that I'm worrying about going from one extreme to the other in terms of version requirements - it feels like there's a step change when you move from things you can get in current release distros people are likely to be using to things that will require a large proportion of people to install extra stuff. At the minute we're more at the other end where it can be hard to figure out who'd even have the oldest versions we support without deliberately seeking them out and keeping them going is noticably making work for people.
Attachment:
signature.asc
Description: PGP signature
