linux-kernel - Re: wpa supplicant/ipw3945, ESSID last char missing

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:	Wed, 04 Oct 2006 15:12:58 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	jt@....hp.com
CC:	Linus Torvalds <torvalds@...l.org>,
	"John W. Linville" <linville@...driver.com>,
	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

Jean Tourrilhes wrote:
> On Wed, Oct 04, 2006 at 11:38:19AM -0700, Linus Torvalds wrote:
>>
>> On Wed, 4 Oct 2006, Jean Tourrilhes wrote:
>>> 	You can't froze kernel userspace API forever. That is simply
>>> not workable
>> Stop arguing this way.
>>
>> It's not what we have ever done. We've _extended_ the API. But we don't 
>> break old ones.
> 
> 	Old APIs get deprecated, and people are forced to the new API,
> which is exactly the same as far as userspace is concerned. This
> transition is exactly the same as what you propose, both kernel API
> coexist for some time, except it happens in userspace instead of in
> kernel, which is an implementation detail.
> 	So, my question is when can I remove the old ESSID API.
> 
>> I don't even see why you argue. Even the people directly involved with 
>> this thing seem to say that it should have some simple translation layer 
>> and do the internal format thing. We've had major subsystem that do that, 
>> and I don't see why you think wireless is so different, and so special in 
>> this respect.
> 
> 	The Wireless people (Jouni, Dan) decided to change the
> *userspace* API. We could translate the new *userspace* API to the old
> kernel API, but I don't see the point.

Kernel API and userspace API are two vastly different things.  We change 
the kernel API all the time.  We _don't_ change the userspace API, 
except when "change" is defined as an additional to an existing API.


>> If you need to break something, you create a new interface, and try to 
>> translate between the two, and maybe you deprecate the old one so that it 
>> can be removed once it's not in use any more.
> 
> 	That's exactly what it hinges on. What is your criteria for
> removing the old ESSID API. My understanding was 6 months.

There is no reason why the old ESSID API cannot live on for years and 
years.  Just like stat(2) version 1 doesn't support modern time 
granularity, old ESSID API won't support the full range of modern 
ESSIDs.  So what?  That's what a new API -- living alongside the old one 
-- is for.

	Jeff



-
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/