3 ms·

> What about legacy systems, which may not have a rust toolchain? Linux's attitude has always been either you keep up or you get dropped - see the lack of any

by lmm 2y ago

> What about legacy systems, which may not have a rust toolchain? Linux's attitude has always been either you keep up or you get dropped - see the lack of any stable driver API and the ruthless pruning of unmaintained drivers. > What about new architectures that may come up in the future? Who's to say they won't have a Rust compiler? Who's to say they will have a C one?

rat87 2y ago
Linux also cant be built by any minimal c compiler for obscure arch, it requires many gcc extensions. Its only because llvm added them that its also can be compiled with llvm
cwillu 2y ago
> Linux's attitude has always been either you keep up or you get dropped Gonna need a citation on that one. Drivers are removed when they don't have users anymore, and a user piping up is enough to keep the driver in the tree: For example: > As suggested by both Greg and Jakub, let's remove the ones that look > are most likely to have no users left and also get in the way of the > wext cleanup. If anyone is still using any of these, we can revert the > driver removal individually. https://lore.kernel.org/lkml/20231030071922.233080-1-glaubitz@physik.fu-berlin.de/T/ https://lore.kernel.org/lkml/20231030071922.233080-1-glaubit... Or the x32 platform removal proposal, which didn't happen against after some users showed up: > > > I'm seriously considering sending a patch to remove x32 support from > > > upstream Linux. Here are some problems with it: > > > > Apparently the main real use case is for extreme benchmarking. It's > > the only use-case where the complexity of maintaining a whole > > development environment and distro is worth it, it seems. Apparently a > > number of Spec submissions have been done with the x32 model. > > > > I'm not opposed to trying to sunset the support, but let's see who complains.. > > I'm just a single user. I do rely on it though, FWIW. > […snipped further discussion] https://lore.kernel.org/lkml/CAPmeqMrVqJm4sqVgSLqJnmaVC5iakjJ_OxGWo4eFbOCxKEx=GA@mail.gmail.com/ https://lore.kernel.org/lkml/CAPmeqMrVqJm4sqVgSLqJnmaVC5iakj...

by lmm 2y ago

rat87 2y ago

Linux also cant be built by any minimal c compiler for obscure arch, it requires many gcc extensions. Its only because llvm added them that its also can be compiled with llvm

cwillu 2y ago

> Linux's attitude has always been either you keep up or you get dropped Gonna need a citation on that one. Drivers are removed when they don't have users anymore, and a user piping up is enough to keep the driver in the tree: For example: > As suggested by both Greg and Jakub, let's remove the ones that look > are most likely to have no users left and also get in the way of the > wext cleanup. If anyone is still using any of these, we can revert the > driver removal individually. https://lore.kernel.org/lkml/20231030071922.233080-1-glaubitz@physik.fu-berlin.de/T/ https://lore.kernel.org/lkml/20231030071922.233080-1-glaubit... Or the x32 platform removal proposal, which didn't happen against after some users showed up: > > > I'm seriously considering sending a patch to remove x32 support from > > > upstream Linux. Here are some problems with it: > > > > Apparently the main real use case is for extreme benchmarking. It's > > the only use-case where the complexity of maintaining a whole > > development environment and distro is worth it, it seems. Apparently a > > number of Spec submissions have been done with the x32 model. > > > > I'm not opposed to trying to sunset the support, but let's see who complains.. > > I'm just a single user. I do rely on it though, FWIW. > […snipped further discussion] https://lore.kernel.org/lkml/CAPmeqMrVqJm4sqVgSLqJnmaVC5iakjJ_OxGWo4eFbOCxKEx=GA@mail.gmail.com/ https://lore.kernel.org/lkml/CAPmeqMrVqJm4sqVgSLqJnmaVC5iakj...