From: "John W. Linville" <linville@tuxdriver.com>
To: David Miller <davem@davemloft.net>
Cc: kalle.valo@iki.fi, johannes@sipsolutions.net,
hidave.darkstar@gmail.com, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] b43: fix ieee80211_rx() context
Date: Mon, 12 Oct 2009 09:38:36 -0400 [thread overview]
Message-ID: <20091012133835.GB27575@tuxdriver.com> (raw)
In-Reply-To: <20091011.200857.141215452.davem@davemloft.net>
On Sun, Oct 11, 2009 at 08:08:57PM -0700, David Miller wrote:
> From: Kalle Valo <kalle.valo@iki.fi>
> Date: Sun, 11 Oct 2009 19:08:58 +0300
>
> > Johannes Berg <johannes@sipsolutions.net> writes:
> >
> >>> > + local_bh_disable();
> >>> > ieee80211_rx(dev->wl->hw, skb);
> >>> > + local_bh_enable();
> >>>
> >>> This is a bit awkward from drivers' point of view, we have to add the
> >>> same code to all mac80211 drivers using either SPI or SDIO buses.
> >>>
> >>> What about adding a new inline function ieee80211_rx_ni() which would
> >>> disable bottom halves like above and call ieee80211_rx()? IMHO that's
> >>> easier for the driver developers to understand and also easier to
> >>> document ("use this function when calling from process context"). If
> >>> this is acceptable, I can create a patch.
> >>
> >> I really don't see the point, since it's just three lines of code, but I
> >> wouldn't mind all that much either.
> >
> > My worry are the developers who even don't know what is a bottom half
> > and might get it all wrong. (Yes, there really are such people.)
>
> And the difference between this and knowing you need to call the
> ieee80211_rx_ni() thing is?
>
> You have to know what the heck a bottom half is to even know that you
> would need to call the ieee80211_rx_ni() thing.
>
> And that's the same amount of knowledge necessary to simply wrap the
> thing in a BH disable/enable sequence.
I'm not sure I see the difference between this and the rationale for
having netif_rx_ni vs. an open-coded version of it? ieee80211_rx_ni
seems like a small amount of code (could even be inline) that
potentially avoids some stupid bugs...?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
next prev parent reply other threads:[~2009-10-12 13:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-11 10:19 [PATCH] b43: fix ieee80211_rx() context Johannes Berg
2009-10-11 10:26 ` Michael Buesch
2009-10-11 10:31 ` Johannes Berg
2009-10-11 10:35 ` Michael Buesch
2009-10-12 7:27 ` Holger Schurig
2009-10-11 10:39 ` David Miller
2009-10-11 11:53 ` Dave Young
2009-10-11 15:59 ` Kalle Valo
2009-10-11 16:02 ` Johannes Berg
2009-10-11 16:08 ` Kalle Valo
2009-10-12 3:08 ` David Miller
2009-10-12 7:49 ` Kalle Valo
2009-10-12 12:29 ` Luciano Coelho
2009-10-12 13:38 ` John W. Linville [this message]
2009-10-12 20:08 ` David Miller
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=20091012133835.GB27575@tuxdriver.com \
--to=linville@tuxdriver.com \
--cc=davem@davemloft.net \
--cc=hidave.darkstar@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=kalle.valo@iki.fi \
--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.