lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 3 Oct 2006 09:38:45 -0400
From:	Theodore Tso <tytso@....edu>
To:	"John W. Linville" <linville@...driver.com>
Cc:	Dan Williams <dcbw@...hat.com>,
	Alessandro Suardi <alessandro.suardi@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, jt@....hp.com,
	Andrew Morton <akpm@...l.org>,
	Norbert Preining <preining@...ic.at>, hostap@...oo.com,
	linux-kernel@...r.kernel.org, ipw3945-devel@...ts.sourceforge.net
Subject: Re: wpa supplicant/ipw3945, ESSID last char missing

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
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
"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
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ