Hi, I'm alex....
I have a notebook Acer Aspire 5920G, with an intel 4965 wireless, system is a Slackware 12 and kernel is my personal recompiled version of 2.6.21.5.
Usually I use the drivers of the version 0.0.* with macsubsystem version 8.0.2, but I've tried to compile the version 0.1.2... a lot of compilation problem. So I think to use mac9.0.2.....
after the make modules of these it's arrived this message....
net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_add':
net/mac80211/wme.c:759: error: dereferencing pointer to incomplete type
net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_remove':
net/mac80211/wme.c:784: error: dereferencing pointer to incomplete type
make[2]: *** [net/mac80211/wme.o] Error 1
make[1]: *** [net/mac80211] Error 2
make: *** [net] Error 2
so I can't compile the new version, but, even if the compilation is not finished, when I retried to compile iwl version 0.1.2, it works. Now for me is impossible to understand, and I'm tring the way to make mac802 subsys work. Can anyone help me....
Another little question... exist a way for make work the wireless led that is always off, even if the wireless works.
Sorry for the request and for the the bad english... it's a lot of time that I don't wrote to a english mailing list (the last was alsa).
Tank you
Alex
----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2
David Miller wrote:
>From: Stephen Clark <[email protected]>
>Date: Tue, 24 Jul 2007 20:30:16 -0400
>
>
>
>>I find it really sad that a hardware vendor that is willing to write
>>and develope drivers for Linux for their hardware aren't helped more
>>by "the community" or is the "the community" only interested in
>>hacking drivers where the manufacturer give no or minimal support?
>>
>>
>
>This is a massive mischaracterization of reality.
>
>I agree with every statement Jeff has made, Intel really is a problem
>child in this area, and consistently so.
>
>The only way we could "help them" more is to take over the code base
>and do the development for them.
>
>The thing you should find truly sad is how Intel handles these
>situations time and time again, rather than the tireless attempts of
>Jeff and others to education them on how to improve the situation.
>
>
>
So if someone in "the community" really wanted to help Intel why don't
they take the
code Intel posts to the ipw3945 ml and put it into where ever it is
really supposed to go?
Instead of whining how Intel doesn't do it right.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On Tue, Jul 24, 2007 at 08:03:37PM -0400, Jeff Garzik wrote:
> Though in fairness, I am a bit disappointed that wireless-dev seems to
> occasionally become a resting place for drivers, rather than just a pit
> stop on the way to upstream. In particular, stuff still has not been
> moved out of drivers/net/wireless/mac80211 and into
> drivers/net/wireless, which is a basic and easy step to get all code
> ready for upstream.
Point taken. I'll apply a series of patches to eliminate the extra
directory. I guess I'll rename the existing bcm43xx and zd1211rw
drivers in wireless-dev as a temporary measure until those ports are
done upstream.
I would definitely like to see more action from mac80211 driver
developers towards getting drivers upstream. With mac80211 merged,
I know of no reason not to get the drivers ready for upstream now so
they can funnel through netdev-2.6 into -mm with plenty of time to
spare before the next merge window.
John
--
John W. Linville
[email protected]
Jeff Garzik wrote:
>James Ketrenos wrote:
>
>
>>Jeff Garzik wrote:
>>
>>
>>
>>>There is a reason why we say "release early, release often." If
>>>wireless developers don't hear from Intel on a regular basis,
>>>
>>>
>>The "community" vs. "Intel" slant is really getting old.
>>*WE* are part of the community. *WE* have submitted patches. *WE* have
>>done work to bring wireless forward. *WE* are wireless developers.
>>
>>It isn't Intel's fault that certain people have historically made it so
>>difficult to get code to into wireless-dev's mac80211 (and eventually
>>*maybe* upstream) that contributors have decided to focus on getting
>>their code out to users through other means.
>>
>>A version of mac80211 being available out-of-tree with features not
>>found in wireless-dev isn't the problem. The problem is that people
>>have made it too difficult to innovate and develop in wireless-dev.
>>
>>
>
>Well, the facts according to my search are:
>
>* last iwlwifi submit was almost two months ago, in a form difficult to
>review and discuss on the mailing list, save for a bug fix. And I note,
>the submission went into wireless-dev rapidly.
>
>* last mac80211 patches were almost three months ago, save for two small
>add-ioctl patches from Mohamed and Hong.
>
>* no one else seems to have the same trouble getting patches in
>
>Whereas other developers are actively posting patches, big and small, to
>linux-wireless on a regular basis. I just don't see much activity at
>all on {linux-kernel,linux-wireless,netdev} from Intel with regards to
>the new wireless.
>
>Intel is the only wireless driver developer doing development
>"elsewhere", rather than where the wireless hackers hang out. Even
>assuming a hypothetical worst case of 100% patch drops, you should be
>working and posting where other developers are also working and posting.
> That is just a BASIC part of the open source kernel engineering process.
>
>Another key part of open source is "release early, release often" so
>that people are aware of your work and needs, and can provide rapid
>feedback. That means posting most patches to linux-wireless as soon as
>they work on your basic quick-test setup. Intel is definitely not
>"releasing early and often" from the LKML perspective.
>
>Though in fairness, I am a bit disappointed that wireless-dev seems to
>occasionally become a resting place for drivers, rather than just a pit
>stop on the way to upstream. In particular, stuff still has not been
>moved out of drivers/net/wireless/mac80211 and into
>drivers/net/wireless, which is a basic and easy step to get all code
>ready for upstream.
>
> Jeff
>
>
>
>
I find it really sad that a hardware vendor that is willing to write and develope drivers for Linux for their hardware aren't helped more by "the community" or is the "the community" only interested in hacking drivers where the manufacturer give no or minimal support?
I appreciate Intel's support for being open and purposely bought a laptop that had an Intel graphics chipset and an Intel wireless card.
My $.02
Steve
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
Whether it was in response to my ranting or not, I give credit where
credit is due: in the time since this thread, a lot more stuff has been
showing up on linux-wireless. It's great to see positive improvement
this rapidly... thanks!
Jeff
Jeff Garzik wrote:
>Stephen Clark wrote:
>
>
>>I understand what you are saying on one hand, but you are also saying
>>that Intel
>>is by themselves and no one in the community is going to help, if Intel
>>can't figure
>>out how to do it the right way.
>>
>>
>
>David referenced "the tireless attempts of Jeff and others to education
>them on how to improve the situation"
>
>
>
>
>>What I am saying why can't someone in the community be a liason
>>between what Intel is doing and wireless-dev? Why does it have to be
>>someone from
>>Intel?
>>
>>
>
>Ideally it is the hardware vendor that maintains their own Linux drivers
>in the upstream kernel. That is the ideal. It scales best and focuses
>knowledge and resources in everyone's best interests.
>
>To answer your question, it does not HAVE to be somebody at Intel. On
>occasion, when a hardware vendor was exceedingly difficult to work with,
>someone in the community will step up and fill that gap.
>
>The problem with such a liaison is that they must maintain a fork of the
>vendor driver themselves, which is time consuming and annoying, because
>you wind up buffering the code and problem complaints from the community
>as well as trying to reconcile that with new vendor driver engineering.
>
>That process, as we saw with skge and tg3 drivers, usually ends up with
>the community maintaining a driver independent of the hardware vendor,
>using the hardware vendor's driver purely as a reference manual, once
>things are out-of-sync enough. That's not generally a situation the
>hardware vendor likes, since they lose a lot of control -- though in
>tg3's case, the driver quality and upstream incentives were such that
>the vendor switched from their own driver to tg3. And now the tg3
>vendor is back in control, actively submitting patches, and overall
>being an excellent example of open source engineering done right.
>
>In general, most incentives rest on Intel to get stuff upstream. That's
>where the process is most efficient, and all involved (Linux users,
>Kernel hackers, and Intel) benefit.
>
>Part of my tireless work is _not_ throwing my hands up in frustration
>and doing it all myself :) but instead trying to counsel on where the
>process is getting stuck.
>
> Jeff
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
Jeff,
Thanks for all you do and taking the time to explain what probably was
apparent
already to a lot of people.
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
Stephen Clark wrote:
> I understand what you are saying on one hand, but you are also saying
> that Intel
> is by themselves and no one in the community is going to help, if Intel
> can't figure
> out how to do it the right way.
David referenced "the tireless attempts of Jeff and others to education
them on how to improve the situation"
> What I am saying why can't someone in the community be a liason
> between what Intel is doing and wireless-dev? Why does it have to be
> someone from
> Intel?
Ideally it is the hardware vendor that maintains their own Linux drivers
in the upstream kernel. That is the ideal. It scales best and focuses
knowledge and resources in everyone's best interests.
To answer your question, it does not HAVE to be somebody at Intel. On
occasion, when a hardware vendor was exceedingly difficult to work with,
someone in the community will step up and fill that gap.
The problem with such a liaison is that they must maintain a fork of the
vendor driver themselves, which is time consuming and annoying, because
you wind up buffering the code and problem complaints from the community
as well as trying to reconcile that with new vendor driver engineering.
That process, as we saw with skge and tg3 drivers, usually ends up with
the community maintaining a driver independent of the hardware vendor,
using the hardware vendor's driver purely as a reference manual, once
things are out-of-sync enough. That's not generally a situation the
hardware vendor likes, since they lose a lot of control -- though in
tg3's case, the driver quality and upstream incentives were such that
the vendor switched from their own driver to tg3. And now the tg3
vendor is back in control, actively submitting patches, and overall
being an excellent example of open source engineering done right.
In general, most incentives rest on Intel to get stuff upstream. That's
where the process is most efficient, and all involved (Linux users,
Kernel hackers, and Intel) benefit.
Part of my tireless work is _not_ throwing my hands up in frustration
and doing it all myself :) but instead trying to counsel on where the
process is getting stuck.
Jeff
Quoting Zhu Yi <[email protected]>:
> On Tue, 2007-07-24 at 08:02 -0700, Axj wrote:
> > so I can't compile the new version, but, even if the compilation
> is
> > not finished, when I retried to compile iwl version 0.1.2, it
> works.
> > Now for me is impossible to understand, and I'm tring the way to
> make
> > mac802 subsys work. Can anyone help me....
>
> iwlwifi-0.1.3 fixed this problem.
>
> Thanks,
> -yi
>
I tried, but peraphs I do someting wrong.... In fact without mac80211-9.0.x is impossibile to compile iwlwifi-0.1.3. But for me I'ts impossible to compile mac-802-9.0.2... give me 2 compile errors when I do "make modules", in the wmc.c. Now, if use the "make patch_kernel" of version of 9.0.2 and compile iwlwifi-0.1.3 it copilke perfect but at the moment to load the module, search a Object that doesn't exist (because if I don't compile the 9.0.2 I have to use 8.0.2). So, if I undestood good, the only way to use the driver version 0.1.x and not the version 0.0.x, is to make work the mac80211 version 9.0.2, and to resolve the compilation problem. It's no so simply like seems to be.
I saw onother exit of thje driver, 1.0.0, but I don't trust so much (at the momente the compination of mac80211 ver 8.0.2 and iwlwifi-0.0.42 work, even if the led doesn't work ad It's impossible to set an "Ad-Hoc" connection. ) so I would like try a CVS or GIT version of the Mac80211 or newer.... I know that a lot of person think that I have to "learn to fish", but I'm a better systemist, but not a excellent programmer (expecially in kernel space).
I would like to tel You tank you for the help....
I hope that one day I will give you as better answer....
----------------------------------------------------------------------
Finally - A spam blocker that actually works.
http://www.bluebottle.com/tag/4
Stephen Clark wrote:
> So if someone in "the community" really wanted to help Intel why don't
> they take the
> code Intel posts to the ipw3945 ml and put it into where ever it is
> really supposed to go?
> Instead of whining how Intel doesn't do it right.
Unscalable.
People in the past sometimes asked Linus, "why didn't you go to $foo.com
website and download the patches? they work for me!" Same reason:
it's unscalable.
For each step in the maintainership pyramid of trust, the number of
people at that level decreases from the previous step. Patches trickle
-up- from sub-maintainers to maintainers to Andrew and finally Linus.
Thus, it is unreasonable for a kernel maintainer to poll $N mailing
lists, coalesce the opinion, grok the code, make sure the code is at a
point where it is OK to push upstream, and then push. That's a
one-to-many operation.
In contrast, a WORKING example of kernel development is a many-to-one
process. Driver maintainers send patches to subsystem maintainers.
Subsystem maintainers send patches to higher-level subsystem
maintainers. High-level subsystem maintainers send patches to Andrew
and Linus.
That's scalable.
Jeff
David Miller wrote:
>From: Stephen Clark <[email protected]>
>Date: Tue, 24 Jul 2007 20:43:13 -0400
>
>
>
>>So if someone in "the community" really wanted to help Intel why
>>don't they take the code Intel posts to the ipw3945 ml and put it
>>into where ever it is really supposed to go?
>>
>>
>
>Because it's better to teach someone how to fish than to continually
>fish for them.
>
>
>
David,
I understand what you are saying on one hand, but you are also saying
that Intel
is by themselves and no one in the community is going to help, if Intel
can't figure
out how to do it the right way.
What I am saying why can't someone in the community be a liason
between what Intel is doing and wireless-dev? Why does it have to be
someone from
Intel?
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
Since Intel continues to develop their mac80211 fork
on their own, you will have to seek support from them at
[email protected].
I keep hearing that Intel intends to come back to working with the
community on mac80211. Alas, that has yet to happen. I want to
believe that it will soon...?
John
On Tue, Jul 24, 2007 at 08:02:12AM -0700, Axj wrote:
> Hi, I'm alex....
>
> I have a notebook Acer Aspire 5920G, with an intel 4965 wireless, system is a Slackware 12 and kernel is my personal recompiled version of 2.6.21.5.
>
> Usually I use the drivers of the version 0.0.* with macsubsystem version 8.0.2, but I've tried to compile the version 0.1.2... a lot of compilation problem. So I think to use mac9.0.2.....
> after the make modules of these it's arrived this message....
>
>
> net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_add':
> net/mac80211/wme.c:759: error: dereferencing pointer to incomplete type
> net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_remove':
> net/mac80211/wme.c:784: error: dereferencing pointer to incomplete type
> make[2]: *** [net/mac80211/wme.o] Error 1
> make[1]: *** [net/mac80211] Error 2
> make: *** [net] Error 2
>
>
> so I can't compile the new version, but, even if the compilation is not finished, when I retried to compile iwl version 0.1.2, it works. Now for me is impossible to understand, and I'm tring the way to make mac802 subsys work. Can anyone help me....
>
> Another little question... exist a way for make work the wireless led that is always off, even if the wireless works.
>
> Sorry for the request and for the the bad english... it's a lot of time that I don't wrote to a english mailing list (the last was alsa).
>
> Tank you
> Alex
>
> ----------------------------------------------------------------------
> Get a free email account with anti spam protection.
> http://www.bluebottle.com/tag/2
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
John W. Linville
[email protected]
Jeff Garzik wrote:
> Intel is definitely not releasing early and often" from the LKML perspective.
I agree the cadence to >>linux-wireless<< has been lacking. But Intel
is releasing early and often. You can check their GIT logs and snapshot
history as evidence of that.
I am very hopeful that the people working on the 802.11n and HT patches,
as well as the developers working on the iwlwifi drivers, will get their
patches together and submitted to linux-wireless for inclusion.
I am also hopeful that those patches will be evaluated on the merit and
value of the functionality they enable.
<soapbox>
If people on linux-wireless don't want contributors to go off and
spend weeks / months at a time working in another sandbox, on another
mailing list, or in a different development community, maybe the
general attitude and approach of the maintainers on linux-wireless
needs to be one which facilitates those individual's contributions,
and helps in encouraging them to do more in the future. Even if those
contributors work for a Big Hardware Vendor.
Working with a community should augment development, not complicate
it or become a burden to it. People should feel better about their
contributions after engaging in a thread in a community where one
of their patches is reviewed; they should feel like progress has been
made, their contributions have been shared, and now others can benefit
from them -- they should not walk away feeling demoralized and berated
for trying.
More often than not, my time on linux-wireless has left me feeling
like the later.
<soapbox/>
James
Hi John,
Just being a user I am not sure what you mean by come back to working
with community? None of
their stuff is hidden is it? Does "the community" make it so hard to get
stuff included that it is
not worth the pain for Intel?
Just wondering.
Steve
John W. Linville wrote:
>Since Intel continues to develop their mac80211 fork
>on their own, you will have to seek support from them at
>[email protected].
>
>I keep hearing that Intel intends to come back to working with the
>community on mac80211. Alas, that has yet to happen. I want to
>believe that it will soon...?
>
>John
>
>On Tue, Jul 24, 2007 at 08:02:12AM -0700, Axj wrote:
>
>
>>Hi, I'm alex....
>>
>>I have a notebook Acer Aspire 5920G, with an intel 4965 wireless, system is a Slackware 12 and kernel is my personal recompiled version of 2.6.21.5.
>>
>>Usually I use the drivers of the version 0.0.* with macsubsystem version 8.0.2, but I've tried to compile the version 0.1.2... a lot of compilation problem. So I think to use mac9.0.2.....
>>after the make modules of these it's arrived this message....
>>
>>
>>net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_add':
>>net/mac80211/wme.c:759: error: dereferencing pointer to incomplete type
>>net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_remove':
>>net/mac80211/wme.c:784: error: dereferencing pointer to incomplete type
>>make[2]: *** [net/mac80211/wme.o] Error 1
>>make[1]: *** [net/mac80211] Error 2
>>make: *** [net] Error 2
>>
>>
>>so I can't compile the new version, but, even if the compilation is not finished, when I retried to compile iwl version 0.1.2, it works. Now for me is impossible to understand, and I'm tring the way to make mac802 subsys work. Can anyone help me....
>>
>>Another little question... exist a way for make work the wireless led that is always off, even if the wireless works.
>>
>>Sorry for the request and for the the bad english... it's a lot of time that I don't wrote to a english mailing list (the last was alsa).
>>
>>Tank you
>>Alex
>>
>>----------------------------------------------------------------------
>>Get a free email account with anti spam protection.
>>http://www.bluebottle.com/tag/2
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>the body of a message to [email protected]
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
>
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
I've tried the driver 0.1.4 with the new (not so new) linux kernel 2.6.22.1 (against the 2.6.21.5 installed on Slackware 12, and it work without any patch. In fact, at the moment of compiling kernel the mac80211 subsystem is already in..... now it works (even if no led and no Ad-Hoc). I really don't try 1.0.0. I will do it. Maybe the fact of the led in only because I don't pass the right option to the modprobe (in ipw2200 was "modprobe ipw2200 led=1") but here is not. For the Ad-Hoc, i try to take a look in source, but maybe isn't present this part or I don't find.
By the way, thank you for the advice and suggestions
Quoting Pavel Roskin <[email protected]>:
I
> On Thu, 2007-07-26 at 08:10 -0700, Axj wrote:
>
> > I saw onother exit of thje driver, 1.0.0, but I don't trust so
> much
> > (at the momente the compination of mac80211 ver 8.0.2 and
> > iwlwifi-0.0.42 work, even if the led doesn't work ad It's
> impossible
> > to set an "Ad-Hoc" connection. )
>
> Actually, it's direct continuation of the 0.0.x series. It's
> unfortunate that the complexity of the build system makes you
> mistrust
> the recent code, although I can relate. I hope it will be
> remedied
> quickly.
>
> It's possible to compile the 1.0.x driver against recent unpatched
> kernels, even against the standard Fedora 7 kernel, by stripping
> support
> for Intel's rate control algorithm:
>
> diff --git a/origin/Makefile b/origin/Makefile
> index 8c0bdc7..c5d966f 100644
> --- a/origin/Makefile
> +++ b/origin/Makefile
> @@ -10,7 +10,7 @@
> # -jpk
>
> obj-$(CONFIG_IWL3945) += iwl3945.o
> -iwl3945-objs = base-3945.o iwl-3945.o iwl-3945-rs.o
> +iwl3945-objs = base-3945.o iwl-3945.o
> CFLAGS_iwl-3945.o = -DIWL=3945
> CFLAGS_iwl-3945-rs.o = -DIWL=3945
> CFLAGS_base-3945.o = -DIWL=3945
> -D"KBUILD_MODNAME=KBUILD_STR(iwl3945)"
> @@ -19,7 +19,7 @@ $(obj)/base-3945.o: $(src)/base.c FORCE
> $(call if_changed_rule,cc_o_c)
>
> obj-$(CONFIG_IWL4965) += iwl4965.o
> -iwl4965-objs = base-4965.o iwl-4965.o iwl-4965-rs.o
> +iwl4965-objs = base-4965.o iwl-4965.o
> CFLAGS_iwl-4965.o = -DIWL=4965
> CFLAGS_iwl-4965-rs.o = -DIWL=4965
> CFLAGS_base-4965.o = -DIWL=4965
> -D"KBUILD_MODNAME=KBUILD_STR(iwl4965)"
> diff --git a/origin/base.c b/origin/base.c
> index eda467e..ee6ac8f 100644
> --- a/origin/base.c
> +++ b/origin/base.c
> @@ -6284,7 +6284,6 @@ static void iwl_alive_start(struct iwl_priv
> *priv)
> /* Unlock so any user space entry points can call back into
> * the driver without a deadlock... */
> mutex_unlock(&priv->mutex);
> - iwl_rate_control_register();
> rc = ieee80211_register_hw(priv->hw);
> priv->hw->conf.beacon_int = 100;
> mutex_lock(&priv->mutex);
> @@ -6950,7 +6949,6 @@ static void iwl_bg_post_associate(struct
> work_struct *data)
> (priv->phymode == MODE_ATHEROS_TURBO)) ?
> IWL_RATE_6M_PLCP : IWL_RATE_1M_PLCP,
> CMD_ASYNC);
> - iwl_rate_scale_init(priv->hw, IWL_AP_ID);
>
> break;
>
> @@ -6967,7 +6965,6 @@ static void iwl_bg_post_associate(struct
> work_struct *data)
> (priv->phymode == MODE_ATHEROS_TURBO)) ?
> IWL_RATE_6M_PLCP : IWL_RATE_1M_PLCP,
> CMD_ASYNC);
> - iwl_rate_scale_init(priv->hw, IWL_STA_ID);
> iwl_send_beacon_cmd(priv);
>
> break;
> @@ -7915,8 +7912,7 @@ static ssize_t show_rs_window(struct device
> *d,
> struct device_attribute *attr,
> char *buf)
> {
> - struct iwl_priv *priv = d->driver_data;
> - return iwl_fill_rs_info(priv->hw, buf, IWL_AP_ID);
> + return 0;
> }
> static DEVICE_ATTR(rs_window, S_IRUGO, show_rs_window, NULL);
>
> @@ -8851,7 +8847,6 @@ static void iwl_pci_remove(struct pci_dev
> *pdev)
>
> if (priv->mac80211_registered) {
> ieee80211_unregister_hw(priv->hw);
> - iwl_rate_control_unregister();
> }
>
> /* ieee80211_unregister_hw calls d_stop, which flushes
>
>
> --
> Regards,
> Pavel Roskin
>
>
----------------------------------------------------------------------
Finally - A spam blocker that actually works.
http://www.bluebottle.com/tag/4
John W. Linville wrote:
> I would definitely like to see more action from mac80211 driver
> developers towards getting drivers upstream. With mac80211 merged,
> I know of no reason not to get the drivers ready for upstream now so
> they can funnel through netdev-2.6 into -mm with plenty of time to
> spare before the next merge window.
Agreed. Getting something upstream is the fastest way to mature a
driver... It gets far less testing and review hiding out in
netdev-2.6.git or wireless-dev.git.
If it works, is relatively clean, and doesn't corrupt data or have
races, push it upstream :)
Jeff
David Miller wrote:
> From: Stephen Clark <[email protected]>
> Date: Tue, 24 Jul 2007 20:43:13 -0400
>
>> So if someone in "the community" really wanted to help Intel why
>> don't they take the code Intel posts to the ipw3945 ml and put it
>> into where ever it is really supposed to go?
>
> Because it's better to teach someone how to fish than to continually
> fish for them.
Yep. Less work for you and me, too, that way :)
Win-win. :)
Jeff
I agree with Stephen, and i purchased a laptop with intel
graphics/wireless for exactly the same reason too.
Now i really hope that this thread instead of continuing as a flamewar
will positively help intel developer to have better interactions with
wireless-dev people, as it would be in the best interest for both.
My =80.02 (but note that they are =80 and not $ :) )
On 7/25/07, Stephen Clark <[email protected]> wrote:
> Jeff Garzik wrote:
>
> >James Ketrenos wrote:
> >
> >
> >>Jeff Garzik wrote:
> >>
> >>
> >>
> >>>There is a reason why we say "release early, release often." If
> >>>wireless developers don't hear from Intel on a regular basis,
> >>>
> >>>
> >>The "community" vs. "Intel" slant is really getting old.
> >>*WE* are part of the community. *WE* have submitted patches. *WE*=
have
> >>done work to bring wireless forward. *WE* are wireless developers.
> >>
> >>It isn't Intel's fault that certain people have historically made i=
t so
> >>difficult to get code to into wireless-dev's mac80211 (and eventual=
ly
> >>*maybe* upstream) that contributors have decided to focus on gettin=
g
> >>their code out to users through other means.
> >>
> >>A version of mac80211 being available out-of-tree with features not
> >>found in wireless-dev isn't the problem. The problem is that peopl=
e
> >>have made it too difficult to innovate and develop in wireless-dev.
> >>
> >>
> >
> >Well, the facts according to my search are:
> >
> >* last iwlwifi submit was almost two months ago, in a form difficult=
to
> >review and discuss on the mailing list, save for a bug fix. And I n=
ote,
> >the submission went into wireless-dev rapidly.
> >
> >* last mac80211 patches were almost three months ago, save for two s=
mall
> >add-ioctl patches from Mohamed and Hong.
> >
> >* no one else seems to have the same trouble getting patches in
> >
> >Whereas other developers are actively posting patches, big and small=
, to
> >linux-wireless on a regular basis. I just don't see much activity a=
t
> >all on {linux-kernel,linux-wireless,netdev} from Intel with regards =
to
> >the new wireless.
> >
> >Intel is the only wireless driver developer doing development
> >"elsewhere", rather than where the wireless hackers hang out. Even
> >assuming a hypothetical worst case of 100% patch drops, you should b=
e
> >working and posting where other developers are also working and post=
ing.
> > That is just a BASIC part of the open source kernel engineering pr=
ocess.
> >
> >Another key part of open source is "release early, release often" so
> >that people are aware of your work and needs, and can provide rapid
> >feedback. That means posting most patches to linux-wireless as soon=
as
> >they work on your basic quick-test setup. Intel is definitely not
> >"releasing early and often" from the LKML perspective.
> >
> >Though in fairness, I am a bit disappointed that wireless-dev seems =
to
> >occasionally become a resting place for drivers, rather than just a =
pit
> >stop on the way to upstream. In particular, stuff still has not bee=
n
> >moved out of drivers/net/wireless/mac80211 and into
> >drivers/net/wireless, which is a basic and easy step to get all code
> >ready for upstream.
> >
> > Jeff
> >
> >
> >
> >
> I find it really sad that a hardware vendor that is willing to write =
and develope drivers for Linux for their hardware aren't helped more by=
"the community" or is the "the community" only interested in hacking d=
rivers where the manufacturer give no or minimal support?
>
> I appreciate Intel's support for being open and purposely bought a la=
ptop that had an Intel graphics chipset and an Intel wireless card.
>
> My $.02
> Steve
> "They that give up essential liberty to obtain temporary safety,
> deserve neither liberty nor safety." (Ben Franklin)
>
> "The course of history shows that as a government grows, liberty
> decreases." (Thomas Jefferson)
>
>
>
>
> ---------------------------------------------------------------------=
----
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browse=
r.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Ipw3945-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
--=20
Ciao
Maurizio
http://stregatto.wordpress.com
"Well we all shine on
Like the moon and the stars and the sun" (John Lennon)
James Ketrenos wrote:
> Jeff Garzik wrote:
>
>> There is a reason why we say "release early, release often." If
>> wireless developers don't hear from Intel on a regular basis,
>
> The "community" vs. "Intel" slant is really getting old.
> *WE* are part of the community. *WE* have submitted patches. *WE* have
> done work to bring wireless forward. *WE* are wireless developers.
>
> It isn't Intel's fault that certain people have historically made it so
> difficult to get code to into wireless-dev's mac80211 (and eventually
> *maybe* upstream) that contributors have decided to focus on getting
> their code out to users through other means.
>
> A version of mac80211 being available out-of-tree with features not
> found in wireless-dev isn't the problem. The problem is that people
> have made it too difficult to innovate and develop in wireless-dev.
Well, the facts according to my search are:
* last iwlwifi submit was almost two months ago, in a form difficult to
review and discuss on the mailing list, save for a bug fix. And I note,
the submission went into wireless-dev rapidly.
* last mac80211 patches were almost three months ago, save for two small
add-ioctl patches from Mohamed and Hong.
* no one else seems to have the same trouble getting patches in
Whereas other developers are actively posting patches, big and small, to
linux-wireless on a regular basis. I just don't see much activity at
all on {linux-kernel,linux-wireless,netdev} from Intel with regards to
the new wireless.
Intel is the only wireless driver developer doing development
"elsewhere", rather than where the wireless hackers hang out. Even
assuming a hypothetical worst case of 100% patch drops, you should be
working and posting where other developers are also working and posting.
That is just a BASIC part of the open source kernel engineering process.
Another key part of open source is "release early, release often" so
that people are aware of your work and needs, and can provide rapid
feedback. That means posting most patches to linux-wireless as soon as
they work on your basic quick-test setup. Intel is definitely not
"releasing early and often" from the LKML perspective.
Though in fairness, I am a bit disappointed that wireless-dev seems to
occasionally become a resting place for drivers, rather than just a pit
stop on the way to upstream. In particular, stuff still has not been
moved out of drivers/net/wireless/mac80211 and into
drivers/net/wireless, which is a basic and easy step to get all code
ready for upstream.
Jeff
From: Stephen Clark <[email protected]>
Date: Tue, 24 Jul 2007 20:30:16 -0400
> I find it really sad that a hardware vendor that is willing to write
> and develope drivers for Linux for their hardware aren't helped more
> by "the community" or is the "the community" only interested in
> hacking drivers where the manufacturer give no or minimal support?
This is a massive mischaracterization of reality.
I agree with every statement Jeff has made, Intel really is a problem
child in this area, and consistently so.
The only way we could "help them" more is to take over the code base
and do the development for them.
The thing you should find truly sad is how Intel handles these
situations time and time again, rather than the tireless attempts of
Jeff and others to education them on how to improve the situation.
From: Stephen Clark <[email protected]>
Date: Tue, 24 Jul 2007 21:05:59 -0400
[ ipw3945-devel removed from CC: as it's subscriber only ]
> I understand what you are saying on one hand, but you are also
> saying that Intel is by themselves and no one in the community is
> going to help, if Intel can't figure out how to do it the right way.
The Intel developers are not a bunch of neophytes who need their hands
held in this kind of situation, stop making it seem this way.
It doesn't take a genius nor an enormous amount of effort to post
one's work on the appropriate mailing list, in a timely and
appropriate manner.
What Intel is doing is hurting users just like you, whether you choose
to see that or not.
Again, you are massively mischaracterizing the situation, and this has
the potential to mislead people, so I will sit here for days and
refute you if that is what it takes.
Jeff should be applauded, instead of put down, for his endless
patience with Intel and the effort he puts forth to educate them.
On Thu, 2007-07-26 at 08:10 -0700, Axj wrote:
> I saw onother exit of thje driver, 1.0.0, but I don't trust so much
> (at the momente the compination of mac80211 ver 8.0.2 and
> iwlwifi-0.0.42 work, even if the led doesn't work ad It's impossible
> to set an "Ad-Hoc" connection. )
Actually, it's direct continuation of the 0.0.x series. It's
unfortunate that the complexity of the build system makes you mistrust
the recent code, although I can relate. I hope it will be remedied
quickly.
It's possible to compile the 1.0.x driver against recent unpatched
kernels, even against the standard Fedora 7 kernel, by stripping support
for Intel's rate control algorithm:
diff --git a/origin/Makefile b/origin/Makefile
index 8c0bdc7..c5d966f 100644
--- a/origin/Makefile
+++ b/origin/Makefile
@@ -10,7 +10,7 @@
# -jpk
obj-$(CONFIG_IWL3945) += iwl3945.o
-iwl3945-objs = base-3945.o iwl-3945.o iwl-3945-rs.o
+iwl3945-objs = base-3945.o iwl-3945.o
CFLAGS_iwl-3945.o = -DIWL=3945
CFLAGS_iwl-3945-rs.o = -DIWL=3945
CFLAGS_base-3945.o = -DIWL=3945 -D"KBUILD_MODNAME=KBUILD_STR(iwl3945)"
@@ -19,7 +19,7 @@ $(obj)/base-3945.o: $(src)/base.c FORCE
$(call if_changed_rule,cc_o_c)
obj-$(CONFIG_IWL4965) += iwl4965.o
-iwl4965-objs = base-4965.o iwl-4965.o iwl-4965-rs.o
+iwl4965-objs = base-4965.o iwl-4965.o
CFLAGS_iwl-4965.o = -DIWL=4965
CFLAGS_iwl-4965-rs.o = -DIWL=4965
CFLAGS_base-4965.o = -DIWL=4965 -D"KBUILD_MODNAME=KBUILD_STR(iwl4965)"
diff --git a/origin/base.c b/origin/base.c
index eda467e..ee6ac8f 100644
--- a/origin/base.c
+++ b/origin/base.c
@@ -6284,7 +6284,6 @@ static void iwl_alive_start(struct iwl_priv *priv)
/* Unlock so any user space entry points can call back into
* the driver without a deadlock... */
mutex_unlock(&priv->mutex);
- iwl_rate_control_register();
rc = ieee80211_register_hw(priv->hw);
priv->hw->conf.beacon_int = 100;
mutex_lock(&priv->mutex);
@@ -6950,7 +6949,6 @@ static void iwl_bg_post_associate(struct work_struct *data)
(priv->phymode == MODE_ATHEROS_TURBO)) ?
IWL_RATE_6M_PLCP : IWL_RATE_1M_PLCP,
CMD_ASYNC);
- iwl_rate_scale_init(priv->hw, IWL_AP_ID);
break;
@@ -6967,7 +6965,6 @@ static void iwl_bg_post_associate(struct work_struct *data)
(priv->phymode == MODE_ATHEROS_TURBO)) ?
IWL_RATE_6M_PLCP : IWL_RATE_1M_PLCP,
CMD_ASYNC);
- iwl_rate_scale_init(priv->hw, IWL_STA_ID);
iwl_send_beacon_cmd(priv);
break;
@@ -7915,8 +7912,7 @@ static ssize_t show_rs_window(struct device *d,
struct device_attribute *attr,
char *buf)
{
- struct iwl_priv *priv = d->driver_data;
- return iwl_fill_rs_info(priv->hw, buf, IWL_AP_ID);
+ return 0;
}
static DEVICE_ATTR(rs_window, S_IRUGO, show_rs_window, NULL);
@@ -8851,7 +8847,6 @@ static void iwl_pci_remove(struct pci_dev *pdev)
if (priv->mac80211_registered) {
ieee80211_unregister_hw(priv->hw);
- iwl_rate_control_unregister();
}
/* ieee80211_unregister_hw calls d_stop, which flushes
--
Regards,
Pavel Roskin
On Tue, 2007-07-24 at 08:02 -0700, Axj wrote:
> so I can't compile the new version, but, even if the compilation is
> not finished, when I retried to compile iwl version 0.1.2, it works.
> Now for me is impossible to understand, and I'm tring the way to make
> mac802 subsys work. Can anyone help me....
iwlwifi-0.1.3 fixed this problem.
Thanks,
-yi
John W. Linville wrote:
> On Tue, Jul 24, 2007 at 02:29:23PM -0400, Stephen Clark wrote:
>
>> Just being a user I am not sure what you mean by come back to working
>> with community? None of
>> their stuff is hidden is it? Does "the community" make it so hard to get
>> stuff included that it is
>> not worth the pain for Intel?
>
> Very simple -- conduct mac80211 development in public on a mailing
> list appropriate to discussion of an in-kernel component rather than
> hiding on a mailing list that is ostensibly for development of a
> specific driver. As the authors of the patches it is incumbent on
> Intel to post them for inclusion upstream. That is the price of good
> citizenship in the Linux community.
Not just that... it's good engineering.
Wireless driver patches that don't make it rapidly to linux-wireless and
upstream rapidly fester. It becomes a real engineering challenge to
sync up with upstream, if you don't make that your primary task to begin
with.
There is a reason why we say "release early, release often." If
wireless developers don't hear from Intel on a regular basis, the
codebases will diverge, wireless hackers will not get the useful
feedback they need, and Intel hackers will not get the useful feedback
they need.
Open source isn't just about a source code license. This is an
-engineering process-. Post -> [merge | revise based on feedback ] ->
<infinity>. The lower the frequency of posting and community
interaction, the less you are actually participating in key portions of
the engineering process.
Jeff
On Wed, Jul 25, 2007 at 01:01:16AM -0700, James Ketrenos wrote:
> Working with a community should augment development, not complicate
> it or become a burden to it. People should feel better about their
> contributions after engaging in a thread in a community where one
> of their patches is reviewed; they should feel like progress has been
> made, their contributions have been shared, and now others can benefit
> from them -- they should not walk away feeling demoralized and berated
> for trying.
I agree with this in principle. After discussions with many of the
developers involved, I am optimistic that the next round of reviews
will be handled more gracefully. The important part now is to get
those patches flowing back to linux-wireless so we can get the process
working again.
John
--
John W. Linville
[email protected]
On Thu, 2007-07-26 at 23:34 -0700, Axj wrote:
>
> I've tried the driver 0.1.4 with the new (not so new) linux kernel
> 2.6.22.1 (against the 2.6.21.5 installed on Slackware 12, and it work
> without any patch. In fact, at the moment of compiling kernel the
> mac80211 subsystem is already in..... now it works (even if no led and
> no Ad-Hoc).
No, there is ad-hoc support in 0.1.4.
Thanks,
-yi
Quoting Zhu Yi <[email protected]>:
> On Thu, 2007-07-26 at 23:34 -0700, Axj wrote:
> >
> > I've tried the driver 0.1.4 with the new (not so new) linux
> kernel
> > 2.6.22.1 (against the 2.6.21.5 installed on Slackware 12, and it
> work
> > without any patch. In fact, at the moment of compiling kernel
> the
> > mac80211 subsystem is already in..... now it works (even if no
> led and
> > no Ad-Hoc).
>
> No, there is ad-hoc support in 0.1.4.
>
> Thanks,
> -yi
>
Maybe.... but don't work... from the version 0.0.36 to no tell me
Impossible to set ...etc etc.... at the first occasion I will post up the error code that give me...
----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2
From: Stephen Clark <[email protected]>
Date: Tue, 24 Jul 2007 20:43:13 -0400
> So if someone in "the community" really wanted to help Intel why
> don't they take the code Intel posts to the ipw3945 ml and put it
> into where ever it is really supposed to go?
Because it's better to teach someone how to fish than to continually
fish for them.
Jeff Garzik wrote:
> There is a reason why we say "release early, release often." If
> wireless developers don't hear from Intel on a regular basis,
The "community" vs. "Intel" slant is really getting old.
*WE* are part of the community. *WE* have submitted patches.
*WE* have done work to bring wireless forward. *WE* are wireless
developers.
It isn't Intel's fault that certain people have historically
made it so difficult to get code to into wireless-dev's mac80211
(and eventually *maybe* upstream) that contributors have decided
to focus on getting their code out to users through other means.
A version of mac80211 being available out-of-tree with features
not found in wireless-dev isn't the problem. The problem is that
people have made it too difficult to innovate and develop in
wireless-dev.
*That* needs to change.
James
On Tue, Jul 24, 2007 at 02:29:23PM -0400, Stephen Clark wrote:
> Just being a user I am not sure what you mean by come back to working
> with community? None of
> their stuff is hidden is it? Does "the community" make it so hard to get
> stuff included that it is
> not worth the pain for Intel?
Very simple -- conduct mac80211 development in public on a mailing
list appropriate to discussion of an in-kernel component rather than
hiding on a mailing list that is ostensibly for development of a
specific driver. As the authors of the patches it is incumbent on
Intel to post them for inclusion upstream. That is the price of good
citizenship in the Linux community.
John
--
John W. Linville
[email protected]
Stephen Clark wrote:
> I find it really sad that a hardware vendor that is willing to write and
> develope drivers for Linux for their hardware aren't helped more by "the
> community"
It's hard to be more helpful without (a) explaining the problems with
the current situation and suggesting corrections, or (b) doing it all
myself.
> or is the "the community" only interested in hacking drivers where
> the manufacturer give no or minimal support?
The more people working on drivers, the wider the workload is spread,
which is a good thing.
The caveat being you cannot just throw any old crap into the kernel,
just because you are a Big Hardware Vendor. Linux thrives precisely
because of the system of engineering review and Internet-scale testing
that we have set up.
We have an engineering process that has proven itself over the past 10+
years. You don't just chuck that out the window because someone doesn't
want to follow the process. Making exceptions for Big Vendors who can't
grok the rules is not how Linux became successful.
These processes all have carefully considered engineering rationale
behind them. The obvious engineering breakdowns occur when you avoid
the standard process... the process that has been delivering stable
hardware support to you and other Linux users.
> I appreciate Intel's support for being open and purposely bought a
> laptop that had an Intel graphics chipset and an Intel wireless card.
Intel gets five stars in the areas of open source CPU, platform, and
graphics support. Intel graphics is really going to kick ass (not that
it doesn't already), and Keith Packard (old-school X11 hacker) is
leading the charge. And Intel networking definitely gets applause for
doing open source networking as well.
But we just don't shove any old vendor driver into the kernel. Not when
we have to maintain these drivers for a decade, often after the vendor
themselves end-of-life's the chip.
Jeff