Maintaining that kind of code is often less about dealing with lingering bugs, than it is about making sure that it's kept in sync with changes to the rest of the kernel that might be relevant. If some kernel structure that the FDD driver uses changes, it needs to know that.

EDIT: Phrasing

> about making sure that it's kept in sync with changes to the rest

At one of my workplaces we had an application that was without a formal supporter and everyone hated to touch it. After I was assigned to dive in to fix a bug, I did a study of how it got that way. I was very surprised by the results I found. Basically, two things went wrong:

* Firstly, due to some mismanagement, the local team moved away, leaving it unsupported.

* Secondly, outside code underwent some paradigm shifts, meaning that anyone who knew outside code found this code to be foreign. Often, people assigned to fix bugs/add features in this code would try to apply the outside paradigms without understanding or adapting the local conventions, creating ugly code interfaces.

Here was the part that amazed me: The time between this code being not-perfect-but-perfectly-normal and becoming ugh-I-hope-I-don't-have-to-touch-that was _6 months_(!)

We've always known that technical debt becomes a problem, but I had no idea it would compound so quickly. Granted, this was at a "post-startup" company going through rapid change as the scope of work kept increasing, but that's still a startlingly fast decay rate for code that was decently written and tested.

Definitely proved to me the value of an active maintainer.

As a witter person that I put it, "code ages like milk, not like wine".

It's remarkable how closely this fits with a system at my company. Without close attention, things can spiral out of control faster than you can imagine.

Yeah, that kind of "process" probably invites code rot. It's subtle, insidious, and yes, sometimes, shockingly quick to set in.

That's what happens when you choose not to have a stable API for drivers. Maybe Linux developers should reconsider that ;-)

Software ages by association. Whatever system it's on or associated with dictates its life span.

Like if you put a soda on a block of ice outside. It will last through the winter and stay solid. Wait until spring and things start getting slippery and wet. The ice and soda are showing signs of aging. Summer hits, and your soda crashes to the ground, spills, everything is just sticky, unusable, and bugs are everywhere.

This is an excellent analogy and I can't understand why it's being downvoted. Software is only as useful as its surroundings find it useful.

A very recent commit fixed some out-of-bounds and a divide-by-zero error: https://github.com/torvalds/linux/commit/47d6a7607443ea43dbc...

> surely all the bugs have been ironed out by now!

Famous last words.

Yeah, but you never know when something somewhere else in the kernel might break it. And not many people have the hardware (not to mention patience) to run a bunch of regression tests for new releases.

> Shouldn’t the floppy driver be incredibly stable code after all these years?

Not if it calls or is called by code that changes more frequently.

Say you modify the HAL interface, then you need to edit this to work as well.

'I'm afraid the floppy kernel can't do that, Dave.'