> > On the other hand, I don't want to see new features added to a
> "stable"
> > kernel series whether they require updated userland tools or not.
>
> In that case, the development cycle of the kernel should be a _lot_
> shorter. At the rate new "stable" kernels come out we would be waiting
> months, if not years for new features to be added.
That's true, though as I and others have already argued, a shorter
development cycle would be a natural result of not back-porting features.
But wait! With the status quo, we already have to wait months or years to
get working features such as RAID and NFS. I'd rather wait months than
years.
> I don't much fancy
> having to wait a year for my brand new piece of hardware to be
> supported and neither will others so you'll probably just see more
> driver development splintering away from the main kernel tree and
> being distributed as patches. Not an ideal solution imho.
That is certainly a disadvantage, but no worse than the current problem
with RAID and NFS. The main advantages of having to patch for new hardware
over having to patch for bugs are 1) the number of patches needed in the
former case is small and constant while in the latter case the number of
patches needed grows without bounds and 2) only new hardware and the rare
systems needing new kernel features need to be patched.
M Carling
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/