All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Tourrilhes <jt@hpl.hp.com>
To: Dan Williams <dcbw@redhat.com>
Cc: linux-wireless@vger.kernel.org,
	Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [RFC PATCH] introduce WEXT scan capabilities
Date: Fri, 7 Dec 2007 11:27:56 -0800	[thread overview]
Message-ID: <20071207192756.GA15864@bougret.hpl.hp.com> (raw)
In-Reply-To: <1197022818.2603.20.camel@localhost.localdomain>

On Fri, Dec 07, 2007 at 05:20:18AM -0500, Dan Williams wrote:
> On Thu, 2007-12-06 at 11:11 -0800, Jean Tourrilhes wrote:
> > On Thu, Dec 06, 2007 at 06:28:39AM -0500, Dan Williams wrote:
> > > See the previous thread about fixing the ap_scan mess.  I think Jean's
> > > correct in asserting that we need more bits for scan capability.
> > > 
> > > This patch introduces scan capability bits for WEXT; hopefully cfg80211
> > > can also pick up equivalent functionality.  Capability bits are provided
> > > for all the current options that may be passed to drivers in the
> > > iw_scan_req structure.  It can be assumed that if the driver reports the
> > > scan capability, that the driver respects the options specified in the
> > > iw_scan_req structure when performing the scan.
> > > 
> > > Clients can use logic like (cribbed from wpa_supplicant's driver_wext.c)
> > > this to figure out whether or not the capability bits are supported:
> > > 
> > > struct iwreq iwr;
> > > struct iw_range *range;
> > > 
> > > <set up iwr/range for request>
> > > 
> > > if (ioctl(drv->ioctl_sock, SIOCGIWRANGE, &iwr) == 0) {
> > > 	u8 minlen = ((char *) &range->scan_capa) - (char *) range + sizeof(range->scan_capa);
> > > 
> > > 	if (iwr.u.data.length >= minlen) {
> > > 		/* SCAN_CAPA is supported */
> > > 	}
> > > }
> > > 
> > > Jean; what do you think?
> > 
> > 	Actually, I like your new proposal. I told you there was a
> > gotcha, you need to add some padding to not screw up userspace. Note
> > that we have already some padding in that structure (look at 'old_*'),
> > so it's not the first time we do that.
> > 	Basically, it should look like the patch below...
> > 
> > 	Regards,
> > 
> > 	Jean
> > 
> > Signed-off-by: Jean Tourrilhes <jt@hpl.hp.com>
> > 
> > --- linux/include/linux/wireless.d1.h   2007-12-06 11:04:16.000000000 -0800
> > +++ linux/include/linux/wireless.h      2007-12-06 11:06:26.000000000 -0800
> > @@ -1040,6 +1040,16 @@ struct   iw_range
> >          * because each entry contain its channel index */
> >  
> >         __u32           enc_capa;       /* IW_ENC_CAPA_* bit field */
> > +
> > +       /* Do *NOT* use those fields, they are just used as padding to get
> > +        * proper alignement with user space */
> > +       __s32           min_pms;
> > +       __s32           max_pms;
> > +       __u16           pms_flags;
> > +       __s32           modul_capa;
> > +       __u32           bitrate_capa;
> > +
> > +       __u32           scan_capa;      /* IW_SCAN_CAPA_* bit field */
> >  };
> 
> Can you explain a bit more about this patch?

	Those fields are defined and used in userspace, please check
wireless.21.h in Wireless Tools.

>  Also, if nobody is
> supposed to use these fields, shouldn't their names be 'reserved' or
> something like that?

	Yeah, you could do that. It does not matter eather way. Using
the same name as userspace has the advantage of making consistency
check easier.

> Thanks,
> Dan

	Regards,

	Jean

  reply	other threads:[~2007-12-07 19:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-06 11:28 [RFC PATCH] introduce WEXT scan capabilities Dan Williams
2007-12-06 19:11 ` Jean Tourrilhes
2007-12-07 10:20   ` Dan Williams
2007-12-07 19:27     ` Jean Tourrilhes [this message]
2007-12-07 21:38       ` Johannes Berg
2007-12-07 22:19         ` Jean Tourrilhes
2007-12-07 22:27           ` Johannes Berg
2007-12-08  2:04       ` David Miller
2007-12-09 17:35         ` Dan Williams
2007-12-09 17:59           ` Dan Williams
2007-12-10  6:10             ` David Miller
2007-12-10 17:23               ` Dan Williams
2007-12-11  0:11                 ` David Miller
2007-12-11  4:22                   ` Dan Williams
2007-12-11  4:51                     ` David Miller
2007-12-11 15:01                       ` Dan Williams
2007-12-10 12:15             ` Johannes Berg
2007-12-10 18:09               ` Jean Tourrilhes
2007-12-11  0:15                 ` David Miller
2007-12-11 13:21                 ` Johannes Berg
2007-12-10 18:11           ` Jean Tourrilhes

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=20071207192756.GA15864@bougret.hpl.hp.com \
    --to=jt@hpl.hp.com \
    --cc=dcbw@redhat.com \
    --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 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.