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]
Message-ID: <20061004232939.GA19647@thunk.org>
Date:	Wed, 4 Oct 2006 19:29:39 -0400
From:	Theodore Tso <tytso@....edu>
To:	Jean Tourrilhes <jt@....hp.com>
Cc:	Linus Torvalds <torvalds@...l.org>,
	"John W. Linville" <linville@...driver.com>,
	Jeff Garzik <jeff@...zik.org>,
	Lee Revell <rlrevell@...-job.com>,
	Alessandro Suardi <alessandro.suardi@...il.com>,
	Norbert Preining <preining@...ic.at>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	johannes@...solutions.net
Subject: Re: wpa supplicant/ipw3945, ESSID last char missing

On Wed, Oct 04, 2006 at 11:59:03AM -0700, Jean Tourrilhes wrote:
> 	That's exactly what it hinges on. What is your criteria for
> removing the old ESSID API. My understanding was 6 months.

Just to make it clear.  The current practice is that 6 months is the
_minimum_, after an extensive discussion on LKML and an understanding
that costs of supporting both the old and the new interface outweighs
the cost and pain to the user community of removing the old interface.
Then after there is an agrement on how long the deprecation window
will be (and sometimes it is negotiated to be longer than six months),
it is documented in

	 /usr/src/linux/Documentation/feature-removal-schedule.txt

But it's never been the case that after six months, we can remove a
feature just because we feel like it, or it's slightly more convenient
to programmers at the cost of imposing pain on users, or at the cost
of discouraging users from testing bleeding edge kernels.

As others have pointed out, we have maintained old stat system call
interfaces for over a ***decade***.  

So perhaps that's something to keep in mind as we start considering
with the next generation wireless interface looks like, and whether it
is sufficiently well defined and has enough forwards and backwards
compatibility, both at the driver level and at the userspace level, so
that we can avoid these sorts of problems going forward.

Regards,

						- Ted

P.S.  Because of all of these changing interfaces, I *still* haven't
been able to get wpa_supplicant working with LEAP so I can get
wireless access to in IBM offices using my ipw3945 driver.  I've
tried, and failed.  Sigh, I guess I'm not smart enough....

-
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