All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: jt@hpl.hp.com
Cc: netdev@vger.kernel.org, "John W. Linville" <linville@tuxdriver.com>
Subject: Re: [PATCH 2.6.18] WE-21 support (core API)
Date: Sat, 2 Sep 2006 02:47:14 +0200	[thread overview]
Message-ID: <200609020247.14755.mb@bu3sch.de> (raw)
In-Reply-To: <20060901221045.GB13975@bougret.hpl.hp.com>

On Saturday 02 September 2006 00:10, Jean Tourrilhes wrote:
> On Fri, Sep 01, 2006 at 08:55:48PM +0200, Michael Buesch wrote:
> > 
> > > 	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?
> 
> 	WE-netlink is optional. And WE-ioctl could be made optional
> (still on the todo list). You can also disable WE-event and WE-iwspy
> for further footprint reduction.

And we don't need all this stuff on these devices? OK, nl80211
can easily be made optional, too.

> > > > 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.
> 
> 	If you are trying to write WE without reading any other code,
> that's true. But that's not the way sane people work. Sane people
> cut'n'paste from other drivers, and then check the source code of
> iwconfig (which is fully commented) in case of doubt.
> 	It's strange, many driver authors are not afraid of asking me
> questions, but some can't manage to do that.

Heh, well. I would say sane code should not raise the questions
in the first place.

> > In my opinion this
> > "One function signature fits all" design used in WE is simply
> > broken by design.
> 
> 	So, are you saying that the 'syscal' design is broken by
> nature ? I've never seen the kernel and glibc people complaining about
> it.

?? All syscalls have the same function signature? I doubt that.

> 	It was designed this way on purpose, because you get low
> footprint and very good scalability. And I've yet to see anyone
> tripped by it.

I don't see how this is lower footprint.
A function pointer is always the same size. Regardless of how
the function looks like.

-- 
Greetings Michael.

-- 
VGER BF report: U 0.5

  reply	other threads:[~2006-09-02  0:50 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
2006-09-01 22:10           ` Jean Tourrilhes
2006-09-02  0:47             ` Michael Buesch [this message]
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=200609020247.14755.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=jt@hpl.hp.com \
    --cc=linville@tuxdriver.com \
    --cc=netdev@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.