netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: jt@hpl.hp.com
Cc: "John W. Linville" <linville@tuxdriver.com>,
	netdev@vger.kernel.org, Javier Achirica <achirica@gmail.com>,
	Simon Kelley <simon@thekelleys.org.uk>,
	Jouni Malinen <jkmaline@cc.hut.fi>,
	"James P. Ketrenos" <ipw2100-admin@linux.intel.com>,
	Zhu Yi <yi.zhu@intel.com>, Pavel Roskin <proski@gnu.org>,
	"Luis R. Rodriguez" <mcgrof@ruslug.rutgers.edu>,
	Jeroen Vreeken <pe1rxq@amsat.org>,
	Michael Wu <flamingice@sourmilk.net>,
	Denis Vlasenko <vda@ilport.com.ua>,
	Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [PATCH 2.6.18] WE-21 support (core API)
Date: Fri, 1 Sep 2006 20:55:48 +0200	[thread overview]
Message-ID: <200609012055.48799.mb@bu3sch.de> (raw)
In-Reply-To: <20060901163558.GB13815@bougret.hpl.hp.com>

On Friday 01 September 2006 18:35, Jean Tourrilhes wrote:
> On Fri, Sep 01, 2006 at 08:54:00AM +0200, Johannes Berg wrote:
> > On Thu, 2006-08-31 at 10:12 -0700, Jean Tourrilhes wrote:
> > 
> > > 	And I strongly disagree with your disagrement ;-)
> > 
> > You're of course free to do that :) But let me explain.
> 
> 	And my explanation is even more simple : let's not throw the
> baby with the bathwater. If things are broken in WE, let's just fix
> it. I've always worked with people working with me.

Fixing would require redesign of some parts, so incompatible ABI
changes. nl80211 actually _does_ fix it by rewriting the stuff.

> 	Note that one thing that worry me with your approach is
> footprint. I've used various embedded devices over the years, such as
> the Gumstix (4MB Flash), and this is why WE was optimised for
> footprint.

Can you please explain in more detail, how WE + the WE-netlink wrapper
has lower footprint than this netlink-only layer?

> > Actually, no. But that's beside the point anyway. Actually, I think that
> > publishing WE over netlink was a mistake.
> 
> 	I don't understand, in the last few years everybody was
> clamoring for a Netlink interface, and now that it is done, people say
> it is a stupid thing. Any specifics ?
> 
> > The real
> > problem with WE is, as I previously said, the ill-defined semantics of
> > both the user-space API and the in-kernel API.
> 
> 	I don't understand why you say it's ill defined, it 100%
> documented in the iwconfig man page.

It is horribly documented.
There is one big union and one magic "extra" parameter.
You have to guess (or look at other implementations) to find
out which element of the union or even if and how to use the extra
parameter. That's a real pain.
And after you found out which element to use, you have to figure
out somehow how to actually use that element. That's nontrivial,
escpecially because some flags (that are not documented) may
magically change the whole semantics of the contents.

In my opinion this
"One function signature fits all" design used in WE is simply
broken by design. It leads to exactly this big union, the
magic extra field and all the other magic flags here and there.
It is in no way clear from looking at the function signature
what to do. But it should be. nl80211 is designed much better here.

-- 
Greetings Michael.

  reply	other threads:[~2006-09-01 18:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30  0:56 [PATCH 2.6.18] WE-21 support (core API) Jean Tourrilhes
2006-08-31 13:32 ` Johannes Berg
2006-08-31 13:51   ` Jouni Malinen
2006-08-31 14:00     ` Johannes Berg
2006-09-06 20:55       ` [RFC] Alternate " John W. Linville
2006-09-06 21:09         ` Michael Buesch
2006-09-06 21:30         ` Jean Tourrilhes
2006-09-08 14:29           ` John W. Linville
2006-09-08 16:13             ` Jean Tourrilhes
2006-09-08 20:04               ` John W. Linville
2006-09-11  9:08               ` Johannes Berg
     [not found]                 ` <20060911162608.GA31459@bougret.hpl.hp.com>
     [not found]                   ` <1158050637.2854.16.camel@ux156>
2006-09-12 16:17                     ` Jean Tourrilhes
2006-09-13  6:17                       ` Johannes Berg
2006-09-06 21:43         ` Larry Finger
2006-09-07  6:42         ` Johannes Berg
2006-08-31 17:12   ` [PATCH 2.6.18] " Jean Tourrilhes
2006-08-31 17:57     ` Michael Buesch
2006-09-01  6:56       ` Johannes Berg
2006-09-01  6:54     ` Johannes Berg
2006-09-01 16:35       ` Jean Tourrilhes
2006-09-01 18:55         ` Michael Buesch [this message]
2006-09-01 22:10           ` Jean Tourrilhes
2006-09-02  0:47             ` Michael Buesch
2006-09-04  8:17               ` Johannes Berg
2006-09-04  8:35             ` Johannes Berg
2006-09-04 14:13               ` Stuffed Crust
2006-09-05 17:06               ` Jean Tourrilhes
2006-09-01 22:27           ` Ulrich Kunitz

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=200609012055.48799.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=achirica@gmail.com \
    --cc=flamingice@sourmilk.net \
    --cc=ipw2100-admin@linux.intel.com \
    --cc=jkmaline@cc.hut.fi \
    --cc=johannes@sipsolutions.net \
    --cc=jt@hpl.hp.com \
    --cc=linville@tuxdriver.com \
    --cc=mcgrof@ruslug.rutgers.edu \
    --cc=netdev@vger.kernel.org \
    --cc=pe1rxq@amsat.org \
    --cc=proski@gnu.org \
    --cc=simon@thekelleys.org.uk \
    --cc=vda@ilport.com.ua \
    --cc=yi.zhu@intel.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).