On Fri, 30 Dec 2005, Adrian Bunk wrote:
> >
> > Now, I'm not saying that we can always support everything that goes on in
> > user space forever, but dammit, we can try damn hard.
>
> Was it a mistake to drop support for ipfwadm and ipchains?
> Was it a mistake to drop support for devsfs?
> Will it be a mistake to drop support for gcc < 3.2?
Those things at least were brewing for _years_. People had lots of
heads-up warning.
> Will it be a mistake to remove the obsolete raw driver?
> Will it be a mistake to drop the Video4Linux API 1 ioctls?
> Will it be a mistake to drop support for pcmcia-cs?
And again, this is something that we've been warnign about. We have.
I'm not talking about never obsoleting bad interfaces at all. I'm talking
about the unnecessary breakage that comes from changes that simply aren't
needed, and that isn't given proper heads-up for.
We used to have a fairly clear point where we could break things, when we
had major kernel releases (ie 2.4 -> 2.6 broke the module loader. It was
documented, and it was unavoidable).
> The fundamental problem is that the current development model
> contains no well-defined points where breakages of the kernel-related
> userspace were allowed and expected by users.
The basic rule should be "never". For example, we now have three different
generations of the "stat()" system call, and yes, we wrote the code to
maintain all three interfaces. Breaking an old one for a new better one
simply wasn't an option.
Now, the more specialized the usage is, the less strict the "never"
becomes. But if something becomes a pain for distribution managers (and
from Dave, it sounds like we've hit that way too often), that definitely
means that we've broken too many things.
In short: I don't think anybody can complain about devfs-like things.
We've kept it up for a _long_ time, and there was tons of help for the
migration. But clearly DaveJ is unhappy, and that implies that we're not
doing as well as we should.
(Which is not to say that we should necessarily bend over backwards to
make sure that DaveJ is _never_ unhappy. We should just try harder).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
