Linux wireless drivers development
 help / color / mirror / Atom feed
From: David Lamparter <lists@diac24.net>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: more nl80211/iw tool code comments
Date: Thu, 14 Jun 2007 16:29:27 +0200	[thread overview]
Message-ID: <20070614142925.GA24414@charon.n2.diac24.net> (raw)
In-Reply-To: <1181759017.29767.117.camel@johannes.berg>

Hi!

On Wed, Jun 13, 2007 at 08:23:37PM +0200, Johannes Berg wrote:
> get_phymode should probably be more strict and not accept things like
> "IEEEabg" as A mode. 
Changed.

> get_iftype should accept "ap-vlan" which str_iftype returns, although
> it's not really useful for use by hand anyway, I think.
"Oups."

> Another thing: Maybe it should be possible to say "phy# 1" in addition
> to "phy phy1" so that it's easier to write scripts that don't care about
> concurrent phy name changes? Just a thought.
Added, using "phy %0" syntax.

The entire iw tool is really just a hack btw...


> iw phy set      [ phy ] DEVICE [ CHANSPEC ] [ name NEWNAME ]
> 
> and we discussed on IRC that it might make sense to have the same for
> nl80211. On the surface, that makes sense, however, it does add a
> complication in that we need to either specify that you cannot combine
> some attributes (which doesn't really make sense), 
Hmm, I can't come up with any example other than using some 11n attribute
with a 11abg phymode... care to hit me with a hint?

>                                                    or we need to take
> quite a bit of care with atomicity; setting the channel and changing the
> phy name can both fail individually but having them in one netlink
> message implies that it's one transaction. I'm not sure the somewhat
> cleaner API and saving one command number is worth the additional
> transactional safety we need to be careful with then.
> 
> So I'd like to reverse my previously stated opinion and say that I now
> think that putting these orthogonal things into different commands would
> be better so that we don't run into this transaction problem.

Well, ... take a look at net/core/rtnetlink.c line 716:

	if (err < 0 && modified && net_ratelimit())
		printk(KERN_WARNING "A link change request failed with "
		       "some changes comitted already. Interface %s may "
		       "have been left with an inconsistent configuration, "
		       "please check.\n", dev->name);

So, if rtnetlink doesn't bother too much about "transaction safety" either,
why should we? If an app wants to know what failed, it can still send SET
requests broken down into pieces, so they will know which piece failed.
Obviously they need to leave some stuff grouped (e.g. PHYMODE and CHANNEL),
but I don't think it's useful to force them do so by breaking stuff into
multiple commands...

(There is no difference really between
	CMD_SET_PHY name=myphy
	CMD_SET_PHY phymode=a channel=1
and
	CMD_SET_PHYNAME name=myphy
	CMD_SET_CHANNEL phymode=a channel=1
but the former allows, if we don't care, to just batch it.)


-David

P.S.: I'm a bit busy and won't have time to work on stuff until approx.
next Monday. Oh and I overdid a bit on the "documentation"...
http://git.spaceboyz.net/nl80211/nl80211-meta.git/master:/nl80211doc.html
(note the quad'ified attempt at associating ;)


  reply	other threads:[~2007-06-14 14:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-13 18:23 more nl80211/iw tool code comments Johannes Berg
2007-06-14 14:29 ` David Lamparter [this message]
2007-06-16 12:17   ` Johannes Berg
2007-06-18  9:42   ` phy mode, channel -> freq mapping (was RE: more nl80211/iw tool code comments) Sandesh Goel
2007-06-18 11:01     ` Johannes Berg
2007-06-18 12:25       ` Tomas Winkler
2007-06-19  4:50         ` Sandesh Goel
2007-06-19  8:59     ` Jiri Benc

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=20070614142925.GA24414@charon.n2.diac24.net \
    --to=lists@diac24.net \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /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