From: Pavel Roskin <proski@gnu.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: John Linville <linville@tuxdriver.com>, Jouni Malinen <j@w1.fi>,
linux-wireless <linux-wireless@vger.kernel.org>,
"Guy, Wey-Yi W" <wey-yi.w.guy@intel.com>,
Samuel Ortiz <samuel@sortiz.org>
Subject: Re: [PATCH] cfg80211: allow wext to remove keys that don't exist
Date: Mon, 18 May 2009 16:04:36 -0400 [thread overview]
Message-ID: <1242677076.30019.5.camel@mj> (raw)
In-Reply-To: <1242669396.29049.2.camel@johannes.local>
On Mon, 2009-05-18 at 19:56 +0200, Johannes Berg wrote:
> Some applications using wireless extensions expect to be able to
> remove a key that doesn't exist. One example is wpa_supplicant
> which doesn't actually change behaviour when running into an
> error while trying to do that, but it prints an error message
> which users interpret as wpa_supplicant having problems.
It sounds like you are working around a userspace problem in the kernel.
> The safe thing to do is not change the behaviour of wireless
> extensions any more, so when the driver reports -ENOENT let
> the wext bridge code return success to userspace. To guarantee
> this, also document that drivers should return -ENOENT when the
> key doesn't exist.
You patch is changing the behavior or wireless extensions. It would be
much more reasonable for wpa_supplicant not to remove non-existent keys
or (if it's unsafe or non-practical for some reason) not to report
-ENOENT to the user.
--
Regards,
Pavel Roskin
next prev parent reply other threads:[~2009-05-18 20:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-18 17:56 [PATCH] cfg80211: allow wext to remove keys that don't exist Johannes Berg
2009-05-18 20:04 ` Pavel Roskin [this message]
2009-05-18 20:06 ` Johannes Berg
2009-05-18 20:37 ` Pavel Roskin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1242677076.30019.5.camel@mj \
--to=proski@gnu.org \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=samuel@sortiz.org \
--cc=wey-yi.w.guy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.