All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Sascha Silbe <silbe@activitycentral.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
	devel <devel@lists.laptop.org>,
	John@xo15-sascha.sascha.silbe.org,
	W.Linville@xo15-sascha.sascha.silbe.org, linville@tuxdriver.com,
	libertas-dev <libertas-dev@lists.infradead.org>,
	netdev <netdev@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Add libertas_disablemesh module parameter to disable mesh interface
Date: Thu, 19 May 2011 12:16:58 -0500	[thread overview]
Message-ID: <1305825421.3271.8.camel@dcbw.foobar.com> (raw)
In-Reply-To: <1305290935-sup-4547@xo15-sascha.sascha.silbe.org>

On Fri, 2011-05-13 at 15:16 +0200, Sascha Silbe wrote:
> Excerpts from Dan Williams's message of Thu May 12 05:11:36 +0200 2011:
> > On Wed, 2011-05-11 at 14:52 +0200, Sascha Silbe wrote:
> > > This allows individual users and deployments to disable mesh support at
> > > runtime, i.e. without having to build and maintain a custom kernel.
> 
> > Does the mesh interface somehow cause problems, even when nothing is
> > using it?
> 
> Some people suspect it does, but there's no hard data showing that. But
> then the problems are often hard to reproduce in the first place, so
> proving a correlation with mesh is even harder.

That's not an excuse for not finding and fixing the problem though.
What problems are we actually talking about here?

> The hardware based mesh support is based on an outdated draft of
> 802.11s and not interoperable with any other device AFAIK. For most
> users Ad-hoc networks are the better option. Disabling mesh support as
> low-level as possible makes it less likely that any remains are causing
> trouble. With at least four layers (firmware, kernel, NM, Sugar)
> involved in managing connectivity and one of the (firmware) being closed
> source, I prefer to simplify things by eliminating three layers for
> functionality we don't intend to use. It makes debugging (and
> blaming ;) ) a lot easier.
> 
> In the field, mesh support is currently disabled using
> /sys/class/net/eth0/lbs_mesh. However, it comes back after resume
> (possibly only if powercycled) and needs to be disabled again by
> post-resume hacks. Race conditions with NM are possible.

That's a parameter handled by the driver; so shouldn't we make sure it's
respected again on resume?

> A user space option would be to teach NM to disable mesh support (at
> runtime - we don't want to ship a custom NM package). I'd expect the
> patch to be much more invasive than the one posted for libertas.

Not really, but we already have on/off for a bunch of other stuff, I
don't see why we can't add one for OLPC mesh.

Dan


      reply	other threads:[~2011-05-19 17:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11 12:52 [PATCH] Add libertas_disablemesh module parameter to disable mesh interface Sascha Silbe
2011-05-11 12:52 ` Sascha Silbe
2011-05-11 17:00 ` Randy Dunlap
2011-05-13 13:26   ` Sascha Silbe
2011-05-13 13:26     ` Sascha Silbe
2011-05-13 13:26     ` Sascha Silbe
2011-05-12  3:11 ` Dan Williams
2011-05-13 13:16   ` Sascha Silbe
2011-05-13 13:16     ` Sascha Silbe
2011-05-13 13:16     ` Sascha Silbe
2011-05-19 17:16     ` Dan Williams [this message]

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=1305825421.3271.8.camel@dcbw.foobar.com \
    --to=dcbw@redhat.com \
    --cc=John@xo15-sascha.sascha.silbe.org \
    --cc=W.Linville@xo15-sascha.sascha.silbe.org \
    --cc=devel@lists.laptop.org \
    --cc=libertas-dev@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=silbe@activitycentral.com \
    /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.