Re: + deprecate-smbfs-in-favour-of-cifs.patch added to -mm tree

[Linus Torvalds <torvalds@osdl.org>]

On Fri, 12 May 2006, John Kelly wrote:
> 
> I just think forward progress would be easier without dragging around
> some of the old baggage in the kernel.

I think that is generally true, but we've actually been pretty successful 
in having a modular enough source tree that most of the time, old code 
simply is old - and doesn't much affect new code.

That is especially true in filesystems. We've had a few fairly painful 
times (the page cache changes in 2.3.x and the switch to the dentry cache 
in 2.1.x(?)), but on the whole we've had a pretty stable VFS interface 
that hasn't needed _that_ much work for individual filesystems.

We've had much bigger problems with drivers, although there the main 
reason for the problems is just that if some interface changes even very 
trivially, there's just so _many_ drivers that they tend to be harder to 
fix up (and they tend to do things that you can't "think about" because 
it's very much due to bugs or specific issues with some random piece of 
hardware that most developers don't even have access to).

Also, while it can be easier in _one_sense_ to move forwards if you drop 
the old stuff, it often ends up making it harder in another sense: it can 
mean, for example, that people or distributions need to do more work to 
update, which in turn can mean that you have a much harder time getting 
the change tested.

Which then in turn can mean that you actually lose more developer time 
than you gained from the code simplification..

So it's not always a very clear-cut thing. For the _users_ (and those are 
who matter most), backwards compatibility is almost always absolutely the 
biggest priority, and everything else comes second.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/