From: Michael Buesch <mbuesch@freenet.de>
To: "David S. Miller" <davem@davemloft.net>
Cc: davej@redhat.com, jgarzik@pobox.com, jbenc@suse.cz,
josejx@gentoo.org, mbuesch@freenet.de,
linux-kernel@vger.kernel.org, bcm43xx-dev@lists.berlios.de,
netdev@vger.kernel.org, laforge@gnumonks.org
Subject: Re: Broadcom 43xx first results
Date: Wed, 7 Dec 2005 14:34:22 +0100 [thread overview]
Message-ID: <200512071434.23706.mbuesch@freenet.de> (raw)
In-Reply-To: <20051206.151919.72043193.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]
On Wednesday 07 December 2005 00:19, you wrote:
> From: Harald Welte <laforge@gnumonks.org>
> Date: Tue, 6 Dec 2005 20:40:47 +0530
>
> > I'm also in favor of merging the devicescape code, but I don't see it
> > happening without somebody taking care to provide all the required
> > levels of interfaces (I see at least three levels of API's that a wireless
> > driver would need, depending on how much stuff is done in
> > hardware/firmware and how much in software.
>
> I hate to say this, but part of the problem is exactly the fact
> that all the implementors have implemented different levels of
> hardware-MAC'ness in their wireless products.
>
> Stated even further, things might have been more consistent if M$ had
> specified a set of driver interfaces into their own softmac stack,
> which I am to understand they are working on now.
>
> So every M$ wireless driver essentially links in their own softmac
> stack, if needed.
>
> This has resulted in a complicated situation for an already
> complicated technology. Therefore, the fact that it's taking this
> long to accomodate all of the cases in the vanilla tree is quite
> understandable.
>
> I'm at the point where I frankly don't care which softmac
> implementation we go with, but rather I'm more concerned that we pick
> _ONE_ and just stick with it, and then adding the necessary interfaces
> and infrastructure as different wireless devices require.
>
> Yes, you hear me right, it's more important to agree to one
> implementation as the basis, even if it's the worst one currently.
> Division of labor is something we simply cannot afford on the wireless
> stack at this time.
I agree with you, and that is exactly what we are doing:
We take the existing code and add functionality to it. If the
added functionality is an external module, well, consinder this
as an extra cookie for devices which do not need MAC handling.
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-12-07 13:34 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1Eiyw4-0003Ab-FW@www1.emo.freenet-rz.de>
2005-12-05 18:00 ` Broadcom 43xx first results Jiri Benc
2005-12-05 18:14 ` Michael Renzmann
2005-12-05 18:46 ` Jeff Garzik
2005-12-05 18:49 ` Jiri Benc
2005-12-05 18:54 ` Jeff Garzik
2005-12-05 19:11 ` Jiri Benc
2005-12-06 7:17 ` Michael Renzmann
[not found] ` <20051205190038.04b7b7c1-IhiK2ZEFs2oCVLCxKZUutA@public.gmane.org>
2005-12-05 18:38 ` Joseph Jezak
2005-12-05 18:55 ` Jiri Benc
2005-12-05 19:08 ` Jeff Garzik
2005-12-05 19:18 ` Jiri Benc
2005-12-05 19:53 ` Dave Jones
2005-12-05 20:09 ` Jeff Garzik
2005-12-06 15:10 ` Harald Welte
2005-12-06 19:05 ` Jeff Garzik
2005-12-07 7:16 ` Harald Welte
2005-12-06 23:19 ` David S. Miller
2005-12-06 23:45 ` Jeff Garzik
2005-12-07 13:34 ` Michael Buesch [this message]
2005-12-08 11:32 ` Jiri Benc
2005-12-08 12:07 ` Jiri Benc
2005-12-08 12:12 ` Arjan van de Ven
2005-12-08 13:03 ` Jiri Benc
2005-12-05 19:10 ` Christoph Hellwig
2005-12-05 19:31 ` Jiri Benc
2005-12-05 19:41 ` Christoph Hellwig
2005-12-05 20:11 ` Jiri Benc
2005-12-06 15:09 ` Pavel Machek
2005-12-06 16:43 ` Ben Greear
2005-12-06 23:25 ` David S. Miller
2005-12-06 19:24 ` Jeff Garzik
2005-12-06 15:04 ` Pavel Machek
2005-12-08 0:00 ` Michael Wu
2005-12-08 1:05 ` Jeff Garzik
2005-12-05 20:23 ` Michael Buesch
2005-12-05 20:42 ` Jiri Benc
2005-12-06 9:26 ` Kyle Moffett
2005-12-06 10:23 ` Luc Saillard
2005-12-06 22:47 Jean Tourrilhes
2005-12-07 7:11 ` Jouni Malinen
2005-12-07 19:16 ` Jean Tourrilhes
2005-12-07 19:47 ` Jouni Malinen
2005-12-07 19:05 ` Jean Tourrilhes
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=200512071434.23706.mbuesch@freenet.de \
--to=mbuesch@freenet.de \
--cc=bcm43xx-dev@lists.berlios.de \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=jbenc@suse.cz \
--cc=jgarzik@pobox.com \
--cc=josejx@gentoo.org \
--cc=laforge@gnumonks.org \
--cc=linux-kernel@vger.kernel.org \
--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 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).