Not really - it changes how the lines are drawn between components, rather than removing any of them.

The EXT4 filesystem driver as an example contains most of the same code whether it is part of the kernel process or is a user process. A virtual filesystem abstraction is needed between the two in either case as well.

The kernel also already has a module system to support loading externally maintained code. You won't necessarily see a benefit from separately maintained drivers that wouldn't already be present.

▲

afandian 5 hours ago | parent [-]

Behind my question was another one: is there too much in the source tree that doesn't _strictly_ need to be?

Maybe not?

I just got the impression that there are a _lot_ of obscure drivers that have to be carried, and are eventually removed causing annoyance. An ABI for the people who cared about that random driver might localise the maintenance burden.

	▲	ZenoArrow 3 hours ago \| parent [-]
		> An ABI for the people who cared about that random driver might localise the maintenance burden. Yes, but one key reason that a stable ABI isn't provided for drivers is to help encourage companies that ship drivers to make their drivers open source. The idea being, if a driver is mainlined into the Linux kernel, the Linux developers will help maintain support for that driver, in exchange for it being released with an open source licence. There are companies (like NVIDIA) that ship closed source drivers for their devices, but they rely on a kernel-side shim that interacts with the userspace driver, and this is seen as second best compared to mainlining the driver in the kernel.