All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Holger Schurig <hs4233@mail.mn-solutions.de>
Cc: libertas-dev@lists.infradead.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Javier Cardona <javier@cozybit.com>
Subject: Re: questions regarding removing the depencency on CONFIG_IEEE80211
Date: Tue, 04 Dec 2007 10:56:47 -0500	[thread overview]
Message-ID: <1196783807.26155.58.camel@localhost.localdomain> (raw)
In-Reply-To: <200712041647.46523.hs4233@mail.mn-solutions.de>

On Tue, 2007-12-04 at 16:47 +0100, Holger Schurig wrote:
> >> > 3. MAX_NETWORK_COUNT
> > Again, the point of using already defined stuff was to take
> > code out of libertas.  If this is in a header, it's pointless
> > to move it back into libertas.
> 
> I haven't found something similar in linux/ieee80211.h, but I 
> don't know if something with this meaning is in some other 
> header file which I don't know. I just doubt it.

We should  move something like this to lib80211 in the end anyway, but
for now make it local to libertas.

> > I assume that the reason you 
> > want to remove the dep on ieee80211 is to remove the
> > requirement to load that module, which moving this define back
> > to libertas wouldn't accomplish.
> 
> And the reason that some people want to remove the old ieee80211 
> code from the kernel source "really soon now" :-)

Yeah; I assume this means folding the ieee80211 stack back to being
private to the ipw* drivers too...

> > If you'd like to propose moving this define to some other
> > shared header that would be better (linux/ieee80211.h?). 
> > Libertas is not the only driver that uses this define (ipw*,
> > airo, libertas).
> 
> Okay, if other's don't object I can do that.

Another lib80211 candidate; but if you really want you can move it back
to libertas and we'll extract it for lib80211 later.

> 
> > > 4. DEFAULT_MAX_SCAN_AGE
> > No, but it does age the scan results after 15 seconds or
> > something.  Or at least it should.  It shouldn't be throwing
> > any AP in the scan list away until it's 15 seconds old.  This
> > define was picked because it was pointless to create yet
> > another define when there was already a usable and established
> > one.
> 
> If I understand you correctly, then this constant should end up 
> in linux/ieee80211.h as well?

When we do lib80211 it should really be private to lib80211 because that
would handle all the scan aging; but if this define isn't appropriate
for other drivers that use ieee80211.h then maybe we keep it private for
now and move it to lib80211 later.

> 
> > > 7. RADIOTAP
> > >
> > > Libertas contains lot's of code for it's monitoring mode,
> > > which uses radiotap. It used "struct net_device
> > > *rtap_net_dev" and "struct ieee80211_device *ieee". It
> > > contains code like
> > >
> > >    priv->rtap_net_dev = alloc_ieee80211(0);
> > >    priv->ieee = netdev_priv(priv->rtap_net_dev);
> > >
> > > and I don't have any knowledge about radiotap and how to
> > > substitue the alloc_ieee80211(). All I could currently to is
> > > to put those sections into #ifdef CONFIG_IEEE80211.
> >
> > Javier might have more comments on this.
> 
> I actually have a WIP patch that removes the ieee80211 
> dependency, it just clashes with my WIP 
> patch "new-scan.patch" :-)
> 
> The patch applies, compiles sparse-clean and is checkpatch clean, 
> so all is well ---- except that it completely disables monitor 
> mode via radiotap. Maybe I add the bunches you said and the ask 
> Javier to take things over, if he wants & has time. Or I split 
> the patch into things that can be committed today and only 
> remove ieee80211-dependency halfway.

That's probably best for the _moment_, need to investigate more what
exact functionality from ieee80211 Javier used for radiotap.

> But then again, ieee80211 is still in the kernel, so there's no 
> haste in making libertas ready for the post-ieee80211 time. So I 
> think I'll wait until David's patches settled.

Yeah, sounds like a plan.

Dan


  reply	other threads:[~2007-12-04 16:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-04 10:40 questions regarding removing the depencency on CONFIG_IEEE80211 Holger Schurig
2007-12-04 10:53 ` Holger Schurig
2007-12-04 14:56   ` Dan Williams
2007-12-04 15:25     ` John W. Linville
2007-12-04 15:29       ` Dan Williams
2007-12-04 15:54         ` Holger Schurig
2007-12-04 16:59         ` Johannes Berg
2007-12-04 17:10           ` Dan Williams
2007-12-04 16:58       ` Johannes Berg
2007-12-04 15:04 ` Dan Williams
2007-12-04 15:47   ` Holger Schurig
2007-12-04 15:56     ` Dan Williams [this message]
2007-12-04 16:57 ` 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=1196783807.26155.58.camel@localhost.localdomain \
    --to=dcbw@redhat.com \
    --cc=hs4233@mail.mn-solutions.de \
    --cc=javier@cozybit.com \
    --cc=libertas-dev@lists.infradead.org \
    --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.