Re: wpa supplicant/ipw3945, ESSID last char missing

On Tue, 2006-10-03 at 09:38 -0400, Theodore Tso wrote:
On Tue, Oct 03, 2006 at 08:49:07AM -0400, John W. Linville wrote:
As Dan points-out, it will be a while before distros (other than
Fedora rawhide and equivalents) have 2.6.19 kernels for general
users. For now, those experiencing this issue should be comfortable
experiencing some breakage...?

So, is the window between now and the release of 2.6.19 big enough
to give the distros time to get wireless-tools and wpa_supplicant
into their update streams? Or do we need to go through the pain of
reverting/delaying WE-21?

There is a fundamental question hiding here, which is whether or not
it is acceptable to break users who are running some large set of
mainline distro's, such as RHEL 4, SLES/SLED 10, Ubuntu Dapper,
et. al, but who want to upgrade to a newer 2.6 kernel?

Many users have moved to Ubuntu Dapper, or RHEL 4, or SLES/SLED 10
because they don't want to deal with a constantly changing/breaking
GNOME/X world, where packages are constantly being updated and
possibly breaking their desktop. Some of these users are in fact
kernel developers, who want to live and test on the bleeding edge, but
who don't want to deal with an unstable Desktop/X world, since that's

I'm certain these people already experience breakage when using new bits
that haven't been settled into their desktop/distro of choice. It
wasn't so long ago (2.6.10 - 2.6.13) that installing a new kernel would
break the expectations of udev, HAL, and libsysfs while sysfs directory
structure was getting laid out for stuff like power management, wireless
devices, etc. If you're a core system developer, you've got to expect
breakage somewhere.

not where their expertise lies. Other users are ones which have to
use a mainstream distribution for one reason or another (maybe they
have software that only works on RHEL 4), but are interested in
testing bleeding edge kernels because they want to help contribute to
testing and quality assurance. Is it acceptable to break them with
ABI changes?

If the answer that it is acceptable to break the "slower moving"
distro's, how much time do we need to allow to elapse before the

I'd point out here that one is not breaking the _distro_, as long as we
assume that distros are internally consistent (which one of the major
points of a distro!). What's getting broken is people who
install/replace distro-provided software with their own bits. In the
first case, the distro people are responsible to making sure that
breakage does not occur, and that distro users are not affected. In the
second case, that responsibility falls to the user who
installed/replaced the distro-provided software, precisely because that
software is no longer distro provided.

We've _got_ to accept that somebody installing their own stuff has
_some_ responsibility to ensure compatibility of the random code they
install. In a perfect world, distros never make a mistake. But usually
a distro has a much broader and deeper set of expertise than any one
person, and is at least peripherally aware of changes coming down the
pike. One single person cannot hope to assume the responsibilities of
many maintainers working by division of labor.

Obviously we don't try to break stuff unintentionally, or when the pain
would be too severe, because we know better than most what's going on
and it's Just Not Nice. But ultimately, whoever is installing the
software bears the consequences of his/her actions, precisely because
they pulled the trigger.

"faster moving" distro's have accepted the necessary userspace bits?
Is it 30 days? 60 days? 90 days? Or do we do it by distribution. If
all of Debian testing, Ubuntu development, Fedora Core n and n-1,
OpenSuse, Gentoo, has accepted the newer bits, is that enough time?

Clearly the wireless updates failed the second series of tests; but we
haven't even decided, amongst kernel developers, under what
circumstances is it permissible to break the first set of distro's.
Clearly in the best of all worlds new interfaces are carefully
documented, and no new interface is introduced without thinking very
carefully about forwards and backwards compatibility. Unfortuately,
the wireless ABI interface is a legacy interface which seems to be
really broken in many different ways.

John, has the wireless community considered creating a new interface
which *is* carefully designed, and supporting both the new and the
legacy interface for 2-3 years until all of the mainstream

Yes, nl80211/cfg80211 (sent to netdev@ last week) is the likely
successor. Please, if you have suggestions for ABI/API-proofability,
review the patch and post suggestions! We all know a carefully designed
is not just about the code, but about the semantics, structures, etc as
well. It would be quite valuable to have everyone's input to make sure
it's as future-proof as possible.

Dan

distributions have had a chance to cycle? It would be hard, I know,
but would it be harder than some of the alternatives, and would it be
worth it?

Regards,

- Ted

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

Relevant Pages

  • Re: New Sarge install
    ... The default kernel after installing is 2.4.27. ... It's very simple to upgrade the kernel to 2.6 when running sarge since ... the distro provides prebuilt kernel-images. ...
    (Debian-User)
  • Re: Reading network interface data in linux
    ... > One could implement modules by installing eg. ethtool and reading speed/duplex ... I have a hunch that the interface that ethtool uses is ... /them/ worry about tracking kernel changes would actually be the most stable ...
    (comp.lang.python)
  • Re: Distributions
    ... | general there are a lot of packages for people to use. ... kernel, have to run on a multitude of different systems, they tend to be ... and slower than if you compile those packages, ... can have that stability with virtually any distro. ...
    (Debian-User)
  • Re: Where are all the updates gone?
    ... base distro they were building it on, so when they went looking, the 18 ... kernel modules needed to run the realtime portions of emc's control ... you watch this little machine carve out whatever I can write the code to ... Copyright 2007 by Maurice Eugene Heskett, ...
    (Fedora)
  • Re: Disappointed with Ubuntu.
    ... I have had the temerity to criticize a distro, ... Installing K/X/Ubuntu 8.04 from a CD is as installing Debian from the 5 ... just those apps he wants to download and install them. ... drives are cheaper now anyway. ...
    (alt.linux)