Re: Development tree, PLEASE?

[Matthew Frost <artusemrys@sbcglobal.net>]

--- Michael Loftis <mloftis@wgops.com> wrote:

> 
> 
> --On January 20, 2006 4:29:44 PM +0000 James Courtier-Dutton 
> <James@superbug.co.uk> wrote:
> 
> > It is unclear what you are really ranting about here. The "stable"
> > kernel is stable or at least as stable as it is going to be. It is
> > left to distros to make it even more stable. The interface to user
> > land has not changed.
> > If all you are ranting about is the move from devfs to udevd, 
> > then all the user land tools dealing with them have been updated
> > already.
> 

Amen.  devfs has sat in the kernel for an entire major release, 2.4, and
gotten dustier and dustier.  It was deprecated when gregkh asked to
remove it *1 YEAR* before the community let him.  1 whole year prior to
the "last chance" email.  You cannot state that it is anyone's fault but
your own that you missed that.  Your complaint, as far as any of us can
dredge a legitimate complaint out of the noise, is a devfs complaint.  If
you wish to protest the removal of an unused, unmaintained, and
long-deprecated subsystem, title your message such that we understand
that you are complaining about that subsystem.  DO NOT protest about the
stability of the kernel series.  That is not your legitimate issue.  If
you have stability problems, find the cause of the system instability and
email the list about it, to get it fixed.  If you have a complaint about
a new commit in a current series, say 2.6.15, or a patch thereunto
appertaining, note the patch, and discuss why it is problematic.

But if all you're whinging about is devfs being out of 2.6 midstream when
 nobody's using it and there are options for those who do, tell us so. 
Then, we can tell you to used udevd or ndevfs and get out of our hair.

> That's the nail on the head exactly.  Why is this being done in an even
> numbered kernel?  This represents an API change that has knock on well 
> outside of the kernel, and should be done in development releases.  Why
> is it LK is the only major project (that I know of) that does this? 
This
> is akin to apache changing the format of httpd.conf and saying in say
> 1.3.38 and saying 'well we made the userland tools too.'

The kernel is a law unto itself because the kernel is a project like
precious few others.  Name a project like unto the kernel, with the
degrees of similarity and applicability for the given solution, and the
solution as it should logically apply to the kernel for the kernel's
similarity to that project, and maybe we'll talk.  Apache is nothing
like.  Linus has long said that "X does it this way" is not a reason to
do it that way.

> 
> >
> > What is the real specific problem you are having?

(Please, do tell, if it's not devfs)

> 
> Well there's a whole grab bag of them that I'll be getting to over the
> next few months, but the most immediate is the fact that I've gotten
new 
> hardware from a venduh that requires me to build a new Debian installer
> and new debian kernels.  I also have custom packages that depend on
devfs
> being there and now it's not.
> 

No.  Wrong.  If there're a whole grab bag, as you say, then you should
post each, as a separate issue, possibly with consistent proposals for
fixing them.  Follow protocol.  Posting a "The Kernel Is Falling" email
gets people riled up, makes you look foolish, and gets nothing fixed. 
Noise.  Send signal.  We'll wait.

Your "venduh" hardware really is a separate issue, unless you mean to say
that your complaint is that you got too used to devfs and now don't know
how to write drivers.  And it doesn't play nice with Debian?  Why, this
is the kernel mailing list.  I'm sorry, you want
debian-mentors@lists.debian.org or debian-devel@lists.debian.org, if
you're a Debian developer, or debian-kernel@lists.debian.org, if it's a
Debian kernel question (I'm sure they've lots of experience with not
using devfs by now), or possibly debian-user@lists.debian.org.  Your
custom packages should have source with them, or available, because they
should be GPL.  Do a little legwork.


> Yes I realise this change isn't out of the blue or anything, but it's
> in a 'stable' kernel.  Why bother calling 2.6 stable?  We may as well
> have stayed at 2.5 if this sort of thing is going to continue to be
> pulled.
>

What sort of thing?  Removal of long-deprecated subsystems that as much
as scream "Don't use me!  I'm going away!"?  That sort of thing?

How many 2.5 kernels could you actually run a production system on?  2.6
is remarkably version-interoperable for a kernel that a) works, b)
continues to get new code applied to it, c) is not dead, and d) everybody
complains about miserably.  It is remarkably stable in function.  Maybe
when we drop ata support for a bio implementation, we'll get a 2.7
series.  That might be a compatibility breaker.  But changing layers of
abstraction while leaving a perfectly functional migration path for users
of old code?  Dust off your brain and follow the well-blazed trail.

Please try to limit yourself to actual issues with actual kernels, and
title your emails something appropriate and non-incendiary.  And, do try
to keep up with current events.
 
> >
> > James
> >
> >
> 
> 
> 
> --
> "Genius might be described as a supreme capacity for getting its
> possessors
> into trouble of all kinds."
> -- Samuel Butler
> -
> 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/
>