What is the purpose of the "intersect" program in CRDA? It builds but it
doesn't seem to be used anywhere. I also notice the CRDA source has its
own nl80211.h header file, as does the source tree for "iw". Shouldn't
userspace tools just include the sanitized kernel header from the
standard gcc include-file locations? Having multiple copies (and
versions) of nl80211.h everywhere seems like a bad idea.
Will CRDA work with AP mode? That's where my primary interest lies (I'm
writing a new driver for an as-yet unsupported chipset). I can see the
usefulness of CRDA in a laptop. I have a much harder time seeing the
benefit of a 250K application to process 3,000 bytes of data
(regulatory.bin) in an embedded AP context where filesystem space is at
a premium.
--
http://www.fastmail.fm - A no graphics, no pop-ups email service
On Fri, Dec 05, 2008 at 02:15:13PM -0800, Dan E wrote:
>
> On Thu, 4 Dec 2008 21:32:48 -0800, "Luis R. Rodriguez"
> <[email protected]> said:
> > On Thu, Dec 4, 2008 at 9:17 PM, Dan E <[email protected]> wrote:
> > > What is the purpose of the "intersect" program in CRDA? It builds but it
> > > doesn't seem to be used anywhere.
> >
> > We use it to check to see if we have to update the world regulatory
> > domain. You run intersect against the regulatory.bin for example to
> > get the intersection of all regulatory domains.
>
> Now it makes sense.
>
> > > I also notice the CRDA source has its
> > > own nl80211.h header file, as does the source tree for "iw". Shouldn't
> > > userspace tools just include the sanitized kernel header from the
> > > standard gcc include-file locations? Having multiple copies (and
> > > versions) of nl80211.h everywhere seems like a bad idea.
> >
> > Yes and no.
> >
> > We keep the latest header in crda and iw so we can get it to compile
> > to work with the latest stuff, even if you don't have support for the
> > new stuff on your old kernel.
>
> But with an old kernel none of that shiny new stuff is going to work
> anyway.
Right.
> > So although iw and crda are built with support for the shiny new stuff
> > the kernel netlink messages which apply to the new stuff simply won't
> > work. This lets you have, for example, an iw and crda for 2.6.28 and
> > still have it working in case you want to test drive wireless-testing
> > (which as stuff for 2.6.29) or compat-wireless (which has
> > wireless-testing stuff backported).
>
> Which is why I kept getting -22 (-EINVAL) return codes when I tried to
> run the crda I built on a 2.6.27.7 kernel. I then went through the
> somewhat painful procedure of setting up my environment to build against
> wireless-testing HEAD. If crda used <linux/nl80211.h> in the first
> place I could have avoided finding that out the hard way.
>
> It makes zero sense IMO to build a userspace tool that's going to
> netlink messages to the kernel which it doesn't understand or, even
> worse, will misinterpret if the various tools are built using
> out-of-sync 'enum nl80211_commmands'. Doing that is like re-inventing
> wireless extensions all over again. So now I have to maintain my own
> branches to replace 'include "nl80211.h"' with 'include
> <linux/nl80211.h>' everywhere. Wonderful.
It makes zero sense for you to package CRDA for 2.6.27 unless you want
to help users of compat-wireless or wireless-testing.
> IW is especially tedious
> because even though the common iw.h includes its own private nl80211
> header, every one of its C source code file also includes it. From my
> perspective as a developer it's cruft that doesn't need to be there and
> which causes unnecessary headaches and maintenance concerns.
Technically speaking we can remove our own packaged nl80211.h but then
users of older kernels won't get to use the new stuff when using
wireless-testing or compat-wireless.
If we remove our own nl80211.h then users would have to compile their
own iw and refer to a new place for the headers or have the distribution
ship several versions of it.
Userspace applications which *do* want to test against a feature can do tests
like:
#ifdef NL80211_NEW_STUFF
#endif
as wpa_supplicant does it, but that's up to each developer.
Here are the #ifdef'able features:
NL80211_CMD_SET_BSS
NL80211_ATTR_HT_CAPABILITY
NL80211_ATTR_BSS_BASIC_RATES
NL80211_ATTR_WIPHY_TXQ_PARAMS
NL80211_ATTR_WIPHY_FREQ
NL80211_ATTR_WIPHY_SEC_CHAN_OFFSET
In CRDA's case I'm sticking to the packaged nl80211.h.
> > > Will CRDA work with AP mode? That's where my primary interest lies (I'm
> > > writing a new driver for an as-yet unsupported chipset). I can see the
> > > usefulness of CRDA in a laptop. I have a much harder time seeing the
> > > benefit of a 250K application to process 3,000 bytes of data
> > > (regulatory.bin) in an embedded AP context where filesystem space is at
> > > a premium.
> >
> > Would you prefer that being duplicated in kernel space by each driver?
> > That's sort of what we had before. Each driver had their own
> > regulatory solution.
>
> Each driver doing its own implementation is orthogonal to kernel vs
> userspace.
Yes but the fact that the database gets updated on regularly (when
the cosmos align, a new war breaks out, a user reads new docs, etc)
and the data actually *is* a database means we want to keep such silly
updates in userspace.
> It could be both common and in the kernel, available for
> every driver to use. I do understand, at a bigger-picture level, why
> it's desirable to put this stuff in userspace. I'll use it for now, but
> I still think it's a solution looking for a problem.
We had a long discussion about this a long time ago and my first
approach was to do it all in-kernel, then people complained and we moved
it to userspace. Now its there and it works well. If you are so
concerned about the size of the database then trim it yourself, make
your let CRDA use it, or go ahead and customize the kernel and define
statically your *one* single regulatory domain.
Supporting regulatory considerations on STA/AP for different countries
requires that you do have some sort of regulatory information somewhere.
Some people keep it in firmware, some in the driver, and some in a
combination of EEPROM and driver or even some info from Windows registry files.
We've generalized what we can from all drivers. If you think you can do a
better job please send patches and go through the review cycle.
If you have actual issues to point out then please point them out or
better yet just send a patch for the solution.
Luis
On Fri, 5 Dec 2008 16:19:56 -0800, "Luis R. Rodriguez" wrote:
>
> <snip>
>
> It makes zero sense for you to package CRDA for 2.6.27 unless you want
> to help users of compat-wireless or wireless-testing.
True, but I'm new to this bleeding-edge development stuff so give me a
break :)
>
> <snip>
>
> Userspace applications which *do* want to test against a feature can do
> tests
> like:
>
> #ifdef NL80211_NEW_STUFF
> #endif
>
> as wpa_supplicant does it, but that's up to each developer.
My goal is writing a new driver for an unsupported chipset and advancing
the mac80211 effort so that things like wpa_supplicant can be made
obsolete sooner rather than later.
> Here are the #ifdef'able features:
>
> NL80211_CMD_SET_BSS
>
> NL80211_ATTR_HT_CAPABILITY
> NL80211_ATTR_BSS_BASIC_RATES
> NL80211_ATTR_WIPHY_TXQ_PARAMS
> NL80211_ATTR_WIPHY_FREQ
> NL80211_ATTR_WIPHY_SEC_CHAN_OFFSET
>
> In CRDA's case I'm sticking to the packaged nl80211.h.
Thanks for the list. As for CRDA and IW, I'm sticking to my local
patches that get rid of that local header file. I can think of no other
project that does that, save for the old wireless extensions.
>
> <snip>
>
> We had a long discussion about this a long time ago and my first
> approach was to do it all in-kernel, then people complained and we moved
> it to userspace. Now its there and it works well. If you are so
> concerned about the size of the database then trim it yourself, make
> your let CRDA use it, or go ahead and customize the kernel and define
> statically your *one* single regulatory domain.
>
> Supporting regulatory considerations on STA/AP for different countries
> requires that you do have some sort of regulatory information somewhere.
> Some people keep it in firmware, some in the driver, and some in a
> combination of EEPROM and driver or even some info from Windows registry
> files.
> We've generalized what we can from all drivers. If you think you can do a
> better job please send patches and go through the review cycle.
I have read all those discussions in the archives. My intent isn't to
re-hash old arguments or open up that debate again. For now I'm going
to accept it for what it is since my development system isn't as
constrained for resources as the ultimate embedded Linux system will be.
The CRDA code itself is excellent and makes a great example for how to
do things with nl80211 and cfg80211.
> If you have actual issues to point out then please point them out or
> better yet just send a patch for the solution.
Indeed. I envision an alternative scheme that can be optionally
selected as part of a "reduced footprint for embedded systems" patch
set/git branch, but that's a ways off. Right now I just want to get my
driver working and advance the userspace tools needed to help develop,
test, and validate its operation. Hopefully I can contribute along the
way to the cfg80211/nl80211 development effort.
Thanks for your comments. You've obviously been doing a lot of work in
this area. I'm still climbing the learning curve, so I value your
insight and experience tremendously.
[OT: Is it correct to reply TO your email addy and CC the list address,
or is it better to "Reply All"? I have to install a real email client
and ditch the webmail interface soon for git purposes.]
--
Dan
--
http://www.fastmail.fm - IMAP accessible web-mail
On Thu, Dec 4, 2008 at 9:17 PM, Dan E <[email protected]> wrote:
> What is the purpose of the "intersect" program in CRDA? It builds but it
> doesn't seem to be used anywhere.
We use it to check to see if we have to update the world regulatory
domain. You run intersect against the regulatory.bin for example to
get the intersection of all regulatory domains.
> I also notice the CRDA source has its
> own nl80211.h header file, as does the source tree for "iw". Shouldn't
> userspace tools just include the sanitized kernel header from the
> standard gcc include-file locations? Having multiple copies (and
> versions) of nl80211.h everywhere seems like a bad idea.
Yes and no.
We keep the latest header in crda and iw so we can get it to compile
to work with the latest stuff, even if you don't have support for the
new stuff on your old kernel.
So although iw and crda are built with support for the shiny new stuff
the kernel netlink messages which apply to the new stuff simply won't
work. This lets you have, for example, an iw and crda for 2.6.28 and
still have it working in case you want to test drive wireless-testing
(which as stuff for 2.6.29) or compat-wireless (which has
wireless-testing stuff backported).
> Will CRDA work with AP mode? That's where my primary interest lies (I'm
> writing a new driver for an as-yet unsupported chipset). I can see the
> usefulness of CRDA in a laptop. I have a much harder time seeing the
> benefit of a 250K application to process 3,000 bytes of data
> (regulatory.bin) in an embedded AP context where filesystem space is at
> a premium.
Would you prefer that being duplicated in kernel space by each driver?
That's sort of what we had before. Each driver had their own
regulatory solution.
Luis
On Sun, Dec 07, 2008 at 01:56:53PM -0800, Dan E wrote:
>
> On Fri, 5 Dec 2008 16:19:56 -0800, "Luis R. Rodriguez" wrote:
>
> > If you have actual issues to point out then please point them out or
> > better yet just send a patch for the solution.
>
> Indeed. I envision an alternative scheme that can be optionally
> selected as part of a "reduced footprint for embedded systems" patch
> set/git branch, but that's a ways off.
Keep in mind CRDA was designed with this in mind, you can already do it,
its why we let you customize your database and build your own CRDA. If
you're doing embedded you could just put together a database of the
things you wnat to support. You can also customize it further if you
have customer RFs for example which operate in strange licensed
frequencies too.
The database we provide is just what is used regularly throughout the
world for normal 802.11n operation.
> [OT: Is it correct to reply TO your email addy and CC the list address,
> or is it better to "Reply All"? I have to install a real email client
> and ditch the webmail interface soon for git purposes.]
It doesn't matter.
Luis
On Thu, 4 Dec 2008 21:32:48 -0800, "Luis R. Rodriguez"
<[email protected]> said:
> On Thu, Dec 4, 2008 at 9:17 PM, Dan E <[email protected]> wrote:
> > What is the purpose of the "intersect" program in CRDA? It builds but it
> > doesn't seem to be used anywhere.
>
> We use it to check to see if we have to update the world regulatory
> domain. You run intersect against the regulatory.bin for example to
> get the intersection of all regulatory domains.
Now it makes sense.
> > I also notice the CRDA source has its
> > own nl80211.h header file, as does the source tree for "iw". Shouldn't
> > userspace tools just include the sanitized kernel header from the
> > standard gcc include-file locations? Having multiple copies (and
> > versions) of nl80211.h everywhere seems like a bad idea.
>
> Yes and no.
>
> We keep the latest header in crda and iw so we can get it to compile
> to work with the latest stuff, even if you don't have support for the
> new stuff on your old kernel.
But with an old kernel none of that shiny new stuff is going to work
anyway.
> So although iw and crda are built with support for the shiny new stuff
> the kernel netlink messages which apply to the new stuff simply won't
> work. This lets you have, for example, an iw and crda for 2.6.28 and
> still have it working in case you want to test drive wireless-testing
> (which as stuff for 2.6.29) or compat-wireless (which has
> wireless-testing stuff backported).
Which is why I kept getting -22 (-EINVAL) return codes when I tried to
run the crda I built on a 2.6.27.7 kernel. I then went through the
somewhat painful procedure of setting up my environment to build against
wireless-testing HEAD. If crda used <linux/nl80211.h> in the first
place I could have avoided finding that out the hard way.
It makes zero sense IMO to build a userspace tool that's going to
netlink messages to the kernel which it doesn't understand or, even
worse, will misinterpret if the various tools are built using
out-of-sync 'enum nl80211_commmands'. Doing that is like re-inventing
wireless extensions all over again. So now I have to maintain my own
branches to replace 'include "nl80211.h"' with 'include
<linux/nl80211.h>' everywhere. Wonderful. IW is especially tedious
because even though the common iw.h includes its own private nl80211
header, every one of its C source code file also includes it. From my
perspective as a developer it's cruft that doesn't need to be there and
which causes unnecessary headaches and maintenance concerns.
> > Will CRDA work with AP mode? That's where my primary interest lies (I'm
> > writing a new driver for an as-yet unsupported chipset). I can see the
> > usefulness of CRDA in a laptop. I have a much harder time seeing the
> > benefit of a 250K application to process 3,000 bytes of data
> > (regulatory.bin) in an embedded AP context where filesystem space is at
> > a premium.
>
> Would you prefer that being duplicated in kernel space by each driver?
> That's sort of what we had before. Each driver had their own
> regulatory solution.
Each driver doing its own implementation is orthogonal to kernel vs
userspace. It could be both common and in the kernel, available for
every driver to use. I do understand, at a bigger-picture level, why
it's desirable to put this stuff in userspace. I'll use it for now, but
I still think it's a solution looking for a problem.
--
http://www.fastmail.fm - Email service worth paying for. Try it for free