Linux 6.13 Staging Clears Out 107k Lines Of Code From Old & Unmaintained Drivers

[NotMine999]

So the drivers in question are being removed precisely because no one wants to maintain them and yet you claim someone will? Why wouldn't they step up right now?

Why is this idiotic statement being upvoted I've not idea.



Where was I wrong exactly?

You decided you had to inject your useless and usually argumentative opinion into this thread?

[Phoronos]

The Linux kernel has no stable internal API/ABI

It is a very good thing because if you try to be backward compatible :
1/ you will be forced to keep outdated bad designs and technics.
2/ you will not be able to adopt some new improvements.

For instance windows must be backward compatible, but it still relies on many bad things that should be removed, but they can't. And they cannot add some new technics because it relies on old stuff ...

[the-burrito-triangle]

The GPIB subsystem sound interesting. I have around $20k in test equipment (mainly HP and Tektronix with some Keithley gear) that uses this interface. HP and others make GPIB to Ethernet controllers (e.g., the E5810A) to interface with these devices remotely and on newer OSes and computers. So I don't know how useful this will be, since most people don't use native (ISA/PCI/PCIe) GPIB host interfaces at the PC anymore. But maybe this provides better USB-to-GPIB support? Guess I need to look into this more now...

[mrg666]

It is so good to see this code clean up. And it is so great that those APIs are changing/evolving in Linux instead of piling up as a rotting mess to be carried over in every new release. Linux is so mean and lean because of that. I wish these clean ups are done more frequently. And let's not forget reiserfs is also deleted recently. I can't wait for the 6.13 release. I think I will make an exception and try to switch over as soon as the RC1 is released.

[Ladis]

You mix just enough fact with hyperbole of two related, yet different, topics to make a bad argument. Stable A$I and In-N-Out Tree.

Yeah, the kernel doesn't have a stable A$I so eventually everything will fail to compile without active maintainers.

Users of in-tree things can also attest to that which is why GKH is pruning the tree to proactively prevent that from happening.

In tree or out, without active maintainers various parts of the kernel will eventually fail to compile. Even with a Stable A$I we risk it being done wrong and needing Stable A$I v2, some new feature being added that needs to be plumbed into existing parts, there's bug fixes or new compiler issues, and more.

I see "stable ABI" is censored in the Linux world .

[mrg666]

Windows having day one support for hardware where as Linux takes months if not years for it to trickle down is a reason why the Linux desktop is never going to happen.

IMHO not having a stable driver API is a big mistake that causes real world problems (e.g. Android updates are a ticking time bomb)

Desktop computing is dead. Mobile computing took over and Android won that. That time bomb you mention is ticking since 2008. I would say it is ticking like a clockwork.

I am so glad those depreciated API's are cleaned up instead of being carried over. I compile my own kernel just to drop those depreciated APIs even faster than distributions prefer to do such as compiling with -march=x86-64-v3. Can you do that with Microsoft crap?

[mrg666]

Just a few examples. I love that I can throw these out from my systems. This is freedom, this is powerful.

# CONFIG_ISA_DMA_API is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
# CONFIG_AGP is not set
# CONFIG_X86_PMEM_LEGACY is not set
# CONFIG_LEGACY_PTYS is not set

[stormcrow]

It is a very good thing because if you try to be backward compatible :
1/ you will be forced to keep outdated bad designs and technics.
2/ you will not be able to adopt some new improvements.

For instance windows must be backward compatible, but it still relies on many bad things that should be removed, but they can't. And they cannot add some new technics because it relies on old stuff ...

I am absolutely sure that FreeBSD has proven this is not true. You can have a stable enough API and ABI sets to allow developers time to work on and stabilize their own designs, projects, and products without pulling the rug out from under them on an unpredictable and irregular basis. On one end of the spectrum is NT land with one extreme form of backwards compatibility. On the other extreme is Linux which will change structures practically at whim. In the middle are more sane systems like BSD, Mac, and some other proprietary and free software OSes that get along just effin fine without screwing their community over regularly and causing more work that may or may not have a completely justifiable reason. Their IS a middle ground, but doubling down on specious reasoning why Linux does it the way it does is fanboism, not reasoned discussion. The middle ground is generally where you have to have a valid articulate reason as to why API or ABI v2 requires a breaking change to v3. Reasoned and articullate. You know, that part of living in a society where you actually communicate, not just yell or talk at people, to get your ideas across.

Before people balk and scream, MacOS does have a predictable schedule and test releases for developers to work with. It's just on a roughly yearly cycle rather than 18 to 24 months with FreeBSD and longer with NetBSD.

[mrg666]

FreeBSD has only proven that an open source OS never really dies. There is none Linux can learn from it anymore. Same thing over decades and decades, of course the API does not change. Nothing added, nothing removed.

[back2未來]

[ with updating/maintaining driver code, there's some difficulty involved:
AFAI_know, there's no summary for changes between kernel versions, that affect parts of driver code (impact of io-related, towards peripherals or within a mainboard system, e. g. chipset, memory, storage or hardware independent, e.g. filesystems, protocols), therefore most efficient method is trying to compile and forward through all compiler warnings and error messages (especially, if demanded for diverse cpu/soc platforms, isa versions and compiler compatibilities),

limited hardware compatibility (or vendors cancelling support for hardware compatibility towards newer systems),

increasing database for firmware binaries (on some linux systems, updating firmware is already a ~1GB directory on real storage consumption and ~1xxMB download) on distros, that don't split the firmware by categories

and there's an alternative for in-tree kernel modules, if required and necessary and compilable:

dkms - Dynamic Kernel Module Support

(GBIP (general purpose interface bus) provides ~8MB/s on parallel 24pin cable/connector, a multi devices bus ("but only one can be the "Controller In Charge" at a time", up to ~15-31 devices) and cable length (passive, altogether) up to ~20m) (thx) ]