linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Cc: linux-wireless@vger.kernel.org,
	Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>,
	Avinash Patil <avinashp@quantenna.com>,
	Vasily Ulyanov <vulyanov@quantenna.com>,
	Marianna Carrera <mcarrera@quantenna.com>
Subject: Re: [RFC PATCH 2/2] nl80211: implement beacon change notifier
Date: Mon, 27 Nov 2017 13:02:24 +0100	[thread overview]
Message-ID: <1511784144.5456.12.camel@sipsolutions.net> (raw)
In-Reply-To: <20171115153547.kkunkrfcivoqcsq2@bars>

On Wed, 2017-11-15 at 18:35 +0300, Sergey Matyukevich wrote:

> In our case, we are experimenting with applications running along with
> hostapd and enabling band steering and client roaming functionality.
> As I mentioned, various approaches are being examined, including
> both pure nl80211-based approach as well as adding direct hooks
> to hostapd.

To be honest, I'm torn on this.

On the one hand, I think it's fairly reasonable functionality, but on
the other hand I'm not sure we should encourage such separate
approaches - it seems to me that will lead to a lot of fragmentation
and much harder debuggability for upstream where these things get used.

It's also a bunch of code we have to maintain, for nothing that seems
of use to the community - since it's the sort of flexibility explicitly
designed for non-public code (otherwise it could just be part of
hostapd; actually it could even if it were non-public, at least in
theory, unless you're planning it as a value-add thing to go with an
open source hostapd ...).

So while I don't want to stop you entirely in your tracks with this,
I'd really prefer you explore other options regarding where to put your
client steering functionality, perhaps even working on hostapd.

johannes

  reply	other threads:[~2017-11-27 12:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-09  9:40 [RFC PATCH 1/2] nl80211: implement NL80211_CMD_GET_BEACON command Sergey Matyukevich
2017-11-09  9:40 ` [RFC PATCH 2/2] nl80211: implement beacon change notifier Sergey Matyukevich
2017-11-13  9:30   ` Johannes Berg
2017-11-13 12:00     ` Sergey Matyukevich
2017-11-13 12:22       ` Johannes Berg
2017-11-15 15:35         ` Sergey Matyukevich
2017-11-27 12:02           ` Johannes Berg [this message]
2017-12-05 20:31             ` Sergey Matyukevich
2017-12-19 17:00               ` Johannes Berg

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=1511784144.5456.12.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=avinashp@quantenna.com \
    --cc=igor.mitsyanko.os@quantenna.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcarrera@quantenna.com \
    --cc=sergey.matyukevich.os@quantenna.com \
    --cc=vulyanov@quantenna.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).