Re: [PATCH] wireless: consolidate on a single escape_essid implementation

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Wed, Sep 24, 2008 at 05:39:31PM -0700, John W. Linville wrote:
> Is there some huge cost I'm overlooking?  If you are afraid of wasting
> a page then build it into the kernel.  Hopefully this module eventually
> gets bigger anyway.

Like I said, just a thought, in general a module for just one routine
seems like complete overkill to me.

> > > Otherwise it needs to live _somewhere_.
> > > The cfg80211 module might make sense, except that the libertas,
> > > ipw2100, and ipw2200 drivers don't use cfg80211 (at least for now).
> >
> > If we want a framework for FullMAC drivers I think cfg80211
> > can play that role just fine as I believe it was designed that way.
> > We could potentialy just add non-wiphy helper routines in there for now
> > as well if all we need is a home for them. What if we want to make
> > use of some of these in other cfg80211 drivers or maybe mac80211?
> 
> Nothing stops that whether or not they are in a different module.

Right, but my point was more towards that if it lives in cfg80211
you don't have to have yet another module loaded -- specially for this
just one routine.

> > > Besides, you have to start _somewhere_.  I have a feeling that this
> > > happened in the first place because there was nowhere for drivers to
> > > share bits of code like this (other than mac80211 or iee80211).
> >
> > Agreed, although I do like to think cfg80211 can play this role
> > as well, unless we want to remain strict about requiring a wiphy
> > for all its callers.
> 
> Sure, it could.  Does it make a difference?

I don't see a point to a "lib80211" for just one routine for now.

> > > I figure there are probably other bits that can be shared, but most of
> > > them probably require at least _some_ recoding.  This is a no-brainer
> > > and it "breaks the ice" for more follow-on work.
> >
> > Sure, my vote goes towards cfg80211 with helpers which are non wiphy specific.
> > The reason being that these drivers *could* also potentially be ported
> > to use cfg80211 eventually and in fact I think this should be encouraged
> > to help cfg80211 move forward to support them and so eventually
> > [if/once] we have a Linux 3.0 we can ditch Wireless Extensions
> > completely.
> >
> > I think an lib80211 would provide for more excuses for people to stuff
> > things in there and help them never cross the line into cfg80211.
> 
> I don't really see where this affects that.  What are 'they' going
> to stuff in there as an alternative to cfg80211 anyway?  If drivers
> suddenly find ways to share WEXT code, that would seem to make
> migrating them to cfg80211 that much easier.

So what will lib80211 be then exactly? If its not some sort of
infrastructure for drivers then why not just stash useful generic
stuff into headers and where appropriate cfg80211? -- Why do we
need another module for this?

> In the meantime, this is currently my bikeshed and I'd prefer to
> paint it like this. :-)

Heh, this is why I said its just my vote.

  Luis