linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:37:17 -0400	[thread overview]
Message-ID: <1242679037.30019.12.camel@mj> (raw)
In-Reply-To: <1242677200.29049.13.camel@johannes.local>

On Mon, 2009-05-18 at 22:06 +0200, Johannes Berg wrote:
> On Mon, 2009-05-18 at 16:04 -0400, Pavel Roskin wrote:
> > 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.
> 
> More a "user problem" rather than "userspace problem"...

Let's give users a break.  They cannot know which error messages are
important and which are not.  Users' attention should not be attracted
to trivial things such as failure to remove something that never
existed.

> > > 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.
> 
> Umm, no... my previous patch changed the behaviour and this restores it.

OK, that makes me more sympathetic to the patch, at least if the change
did not get exposed in any released kernel.

-- 
Regards,
Pavel Roskin

      reply	other threads:[~2009-05-18 20:37 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
2009-05-18 20:06   ` Johannes Berg
2009-05-18 20:37     ` Pavel Roskin [this message]

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=1242679037.30019.12.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).