From: Jeff Garzik <jeff@garzik.org>
To: Michael Wu <flamingice@sourmilk.net>
Cc: David Miller <davem@davemloft.net>,
"John W. Linville" <linville@tuxdriver.com>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: Please pull 'adm8211' branch of wireless-2.6
Date: Sun, 16 Sep 2007 03:50:25 -0400 [thread overview]
Message-ID: <46ECE041.3090001@garzik.org> (raw)
In-Reply-To: <200709160047.45128.flamingice@sourmilk.net>
Michael Wu wrote:
> On Saturday 15 September 2007 20:56, Jeff Garzik wrote:
>>>>> + if (flags & IFF_PROMISC)
>>>>> + dev->flags |= IEEE80211_HW_RX_INCLUDES_FCS;
>>>>> + else
>>>>> + dev->flags &= ~IEEE80211_HW_RX_INCLUDES_FCS;
>>>> why does promisc dictate inclusion of FCS?
>>> Because that's the way the hardware works.
>> Why not always include it, regardless of promisc?
>>
> I really do mean that's how the hardware works. If you turn on the promisc bit
> in the hardware (which IFF_PROMISC causes), it starts including the FCS, but
> if the bit is not set, the FCS is not included in frames.
OK, I was confused by the name. Based on the constant's name, I was
assuming that you could unconditionally enable it, promisc or not.
Nevermind. I thought that was a hardware rather than software bit.
> What form of debugging are you talking about? I don't see how it makes a
> difference for debugging. The type checking provided by enums won't make a
When you are tracing through with kgdb, the code is actually readable.
You see
dev->flags |= IEEE80211_HW_RX_INCLUDES_FCS;
rather than the far more obtuse
dev->flags |= 8;
Ditto for any time you have to read pre-processed source code. I do so
at least once a month, since post-cpp code shows you precisely what the
compiler is munching, after all the macro magic goes away.
Jeff
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Garzik <jeff-o2qLIJkoznsdnm+yROfE0A@public.gmane.org>
To: Michael Wu <flamingice-R9e9/4HEdknk1uMJSBkQmQ@public.gmane.org>
Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
"John W. Linville"
<linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Please pull 'adm8211' branch of wireless-2.6
Date: Sun, 16 Sep 2007 03:50:25 -0400 [thread overview]
Message-ID: <46ECE041.3090001@garzik.org> (raw)
In-Reply-To: <200709160047.45128.flamingice-R9e9/4HEdknk1uMJSBkQmQ@public.gmane.org>
Michael Wu wrote:
> On Saturday 15 September 2007 20:56, Jeff Garzik wrote:
>>>>> + if (flags & IFF_PROMISC)
>>>>> + dev->flags |= IEEE80211_HW_RX_INCLUDES_FCS;
>>>>> + else
>>>>> + dev->flags &= ~IEEE80211_HW_RX_INCLUDES_FCS;
>>>> why does promisc dictate inclusion of FCS?
>>> Because that's the way the hardware works.
>> Why not always include it, regardless of promisc?
>>
> I really do mean that's how the hardware works. If you turn on the promisc bit
> in the hardware (which IFF_PROMISC causes), it starts including the FCS, but
> if the bit is not set, the FCS is not included in frames.
OK, I was confused by the name. Based on the constant's name, I was
assuming that you could unconditionally enable it, promisc or not.
Nevermind. I thought that was a hardware rather than software bit.
> What form of debugging are you talking about? I don't see how it makes a
> difference for debugging. The type checking provided by enums won't make a
When you are tracing through with kgdb, the code is actually readable.
You see
dev->flags |= IEEE80211_HW_RX_INCLUDES_FCS;
rather than the far more obtuse
dev->flags |= 8;
Ditto for any time you have to read pre-processed source code. I do so
at least once a month, since post-cpp code shows you precisely what the
compiler is munching, after all the macro magic goes away.
Jeff
next prev parent reply other threads:[~2007-09-16 7:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-15 13:22 Please pull 'adm8211' branch of wireless-2.6 John W. Linville
2007-09-15 13:22 ` John W. Linville
2007-09-15 17:00 ` John W. Linville
2007-09-15 17:00 ` John W. Linville
2007-09-15 18:25 ` David Miller
2007-09-15 18:25 ` David Miller
2007-09-16 2:36 ` John W. Linville
2007-09-16 2:36 ` John W. Linville
2007-09-16 3:26 ` Jeff Garzik
2007-09-16 3:26 ` Jeff Garzik
2007-09-15 21:32 ` Jeff Garzik
2007-09-15 21:32 ` Jeff Garzik
2007-09-16 0:16 ` Michael Wu
2007-09-16 0:16 ` Michael Wu
2007-09-16 0:56 ` Jeff Garzik
2007-09-16 4:47 ` Michael Wu
2007-09-16 4:50 ` David Miller
2007-09-16 5:00 ` Michael Wu
2007-09-16 5:00 ` Michael Wu
2007-09-16 7:50 ` Jeff Garzik [this message]
2007-09-16 7:50 ` Jeff Garzik
2007-09-16 0:37 ` Michael Wu
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=46ECE041.3090001@garzik.org \
--to=jeff@garzik.org \
--cc=davem@davemloft.net \
--cc=flamingice@sourmilk.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@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.