On Thu, 08 Dec 2005 13:12:44 +0100, Arjan van de Ven wrote:
> this argument is analogue to the adaptec SAS driver one about the scsi
> host structure. ieee80211 should be a LIBRARY of functions that can do
> things,
Unfortunately, it is not possible to implement ieee80211 as a library,
because you
> 3. Most of WE calls can be handled by ieee80211 itself. The rest should
> be propagated to a driver in some easier way than requiring driver to
> deal with the whole WE stuff itself. Also, exporting callbacks from
> ieee80211 that driver has to set as particular WE handlers seems to be
> unneces
On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik wrote:
> > Unfortunately, the only long-term solution is to rewrite completely the
> > current in-kernel ieee80211 code (I would not call it a "stack") or
> > replace it with something another. The current code was written for
> > Intel devices and it
On Wed, 7 Dec 2005 14:34:22 +0100, Michael Buesch wrote:
> 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 MA
Michael Wu wrote:
The softmac code that is still in adm8211 is actually based on an early
version of the softmac code that Jouni made for Devicescape. The Devicescape
code does much more useful stuff than the code currently in the kernel. Sure,
I can and have been porting adm8211 to the new ker
On Monday 05 December 2005 14:31, Jiri Benc wrote:
> > And Joseph &
> > friends are writing a module to support softmac cards in that framework,
> > which is one of the most urgently needed things right now, because all
> > the existing softmac frameworks don't work with that code.
>
> And authors
On Wed, Dec 07, 2005 at 11:16:22AM -0800, Jean Tourrilhes wrote:
> Well, the burning question is : Is it possible to include your
> Atheros driver in the Linux kernel ? Meaning, will it be released, and
> will it contain a binary blob ?
If that were possible, it would have been released wit
On Tue, Dec 06, 2005 at 02:47:28PM -0800, jt wrote:
>
> MadWifi stack :
> drivers using it : MadWifi (non GPL)
> drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink
Sam kindly pointed out that my statement above may be
confusing. It should read :
MadWifi stack
On Tue, Dec 06, 2005 at 11:11:02PM -0800, Jouni Malinen wrote:
> On Tue, Dec 06, 2005 at 02:47:28PM -0800, Jean Tourrilhes wrote:
>
> > DeviceScape stack :
> > drivers using it : ?
> > potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
>
> It's mainly used with Atheros chipsets
On Wednesday 07 December 2005 00:19, you wrote:
> From: Harald Welte <[EMAIL PROTECTED]>
> 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 interface
On Tue, Dec 06, 2005 at 02:47:28PM -0800, Jean Tourrilhes wrote:
> DeviceScape stack :
> drivers using it : ?
> potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
It's mainly used with Atheros chipsets nowadays, but it has been used
with couple of other chipsets, too, includ
On Tue, Dec 06, 2005 at 02:05:07PM -0500, Jeff Garzik wrote:
> Harald Welte wrote:
> >I also think that there is a lack of knowledge on the architecture of
> >802.11 low-level protocols and drivers among many people (including
> >myself) in the network community. Only this way I can explain why th
David S. Miller wrote:
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
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 06 Dec 2005 08:43:39 -0800
> Merge now even if it breaks the current tree?
DCCP is a good counter example, zero --> some functionality is
always preferred. Our DCCP stack is far from being finished, but
it is in there and getting polished and maint
From: Harald Welte <[EMAIL PROTECTED]>
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
> dr
Jiri Benc wrote :
> On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
> > Use the stack that's already in the kernel.
> >
> > Encouraging otherwise hinders continued wireless progress under Linux.
>
> There is nothing like a "802.11 stack" currently in the kernel,
> regardless what James Ket
Pavel Machek wrote:
No, it does not work like that. You don't get nice, reviewable,
mergeable patches by developing code independently for 3 years or so
then attempting merge.
If devicescape code is better than mainline, merge it _now_. If it is
not, drop it and start from mainline code.
Agree
Harald Welte wrote:
I also think that there is a lack of knowledge on the architecture of
802.11 low-level protocols and drivers among many people (including
myself) in the network community. Only this way I can explain why there
are always people who claim that the kernel already has a 802.11
'
Pavel Machek wrote:
Hi!
That's because you still don't get how we do development. The last thing
we want is full-scale rewrites. Submit patches to fix things based on
whatever you want but do it incremental.
We have got almost finished and working stack. Everything we need to do
is:
1. ide
Hi!
> > That's because you still don't get how we do development. The last thing
> > we want is full-scale rewrites. Submit patches to fix things based on
> > whatever you want but do it incremental.
>
> We have got almost finished and working stack. Everything we need to do
> is:
> 1. identify
Hi!
> > Please stop beeing a freaking jackass. There are various projects using
> > the current code. It's not perfect but people are working on it.
>
> Yes, and everyone implements his own softmac (this is the third one I
> know about). I tried to put all of these efforts together (google
> th
On Mon, Dec 05, 2005 at 02:53:29PM -0500, Dave Jones wrote:
> > ieee80211 is used by Intel. Some bits used by HostAP, which also
> > duplicates a lot of ieee80211 code. And bcm43xx. And another couple
> > drivers found in -mm or out-of-tree.
>
> Orinoco also uses it now no ?
Dave, the Ori
On Tue, Dec 06, 2005 at 04:26:50AM -0500, Kyle Moffett wrote:
> On Dec 05, 2005, at 15:42, Jiri Benc wrote:
> >On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
> >>This is __not__ "yet another stack". It is an _extension_. It is
> >>all about management frames, which the in-kernel code d
On Dec 05, 2005, at 15:42, Jiri Benc wrote:
On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
This is __not__ "yet another stack". It is an _extension_. It is
all about management frames, which the in-kernel code does not
manage.
But this code should be part of the stack, as nearly
Hi.
On Mon, 2005-12-05 at 13:46 -0500, Jeff Garzik wrote:
> > Although I'm a bit biased towards MadWifi, I'd second your suggestion to
> > make use of the Devicescape code. The benefit of having a fully-blown
> > 802.11 stack in the kernel that drivers can make use of has been
> > discussed before
On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
> This is __not__ "yet another stack". It is an _extension_.
> It is all about management frames, which the in-kernel code
> does not manage.
But this code should be part of the stack, as nearly every driver needs
it. Management handling sho
On Monday 05 December 2005 19:00, you wrote:
> On Sun, 04 Dec 2005 19:50:08 +0100, [EMAIL PROTECTED] wrote:
> > The team is in the progress of writing a SoftwareMAC layer,
> > which is needed for the bcm device. The SoftMAC is still very
> > incomplete. So do not expect to do any fancy stuff like W
On Mon, 5 Dec 2005 19:41:46 +, Christoph Hellwig wrote:
> None of them made it into the kernel tree. As soon as we'll have an
> acceptable one everyone will have to use and improve it. I personally
> couldn't care less what we start with.
Same with me.
> That's because you still don't get h
Dave Jones wrote:
On Mon, Dec 05, 2005 at 02:08:28PM -0500, Jeff Garzik wrote:
> Jiri Benc wrote:
> >On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> >
> >>We're not writing an entire stack. We're writing a layer that sits in
> >>between the current ieee80211 stack that's already
On Mon, Dec 05, 2005 at 02:08:28PM -0500, Jeff Garzik wrote:
> Jiri Benc wrote:
> >On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> >
> >>We're not writing an entire stack. We're writing a layer that sits in
> >>between the current ieee80211 stack that's already present in the kerne
On Mon, Dec 05, 2005 at 08:31:21PM +0100, Jiri Benc wrote:
> > And Joseph &
> > friends are writing a module to support softmac cards in that framework,
> > which is one of the most urgently needed things right now, because all the
> > existing softmac frameworks don't work with that code.
>
> And
On Mon, 5 Dec 2005 19:10:08 +, Christoph Hellwig wrote:
> Please stop beeing a freaking jackass. There are various projects using
> the current code. It's not perfect but people are working on it.
Yes, and everyone implements his own softmac (this is the third one I
know about). I tried to p
On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik wrote:
> Patently false.
>
> ieee80211 is used by Intel. Some bits used by HostAP, which also
> duplicates a lot of ieee80211 code. And bcm43xx. And another couple
> drivers found in -mm or out-of-tree.
Hostap uses only encryption code, which w
On Mon, Dec 05, 2005 at 07:55:43PM +0100, Jiri Benc wrote:
> Unfortunately, the only long-term solution is to rewrite completely the
> current in-kernel ieee80211 code (I would not call it a "stack") or
> replace it with something another. The current code was written for
> Intel devices and it doe
On Mon, 05 Dec 2005 13:54:00 -0500, Jeff Garzik wrote:
> Complete bullshit. There is obviously 802.11 generic code in the
> kernel, and that's what _I_ am saying, because it's true.
>
> If it doesn't support your favorite wireless chipset, then submit patches.
I have no favorite chipset. I read
Jiri Benc wrote:
On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
We're not writing an entire stack. We're writing a layer that sits in
between the current ieee80211 stack that's already present in the kernel
and drivers that do not have a hardware MAC. Since ieee80211 is already
in
On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> We're not writing an entire stack. We're writing a layer that sits in
> between the current ieee80211 stack that's already present in the kernel
> and drivers that do not have a hardware MAC. Since ieee80211 is already
> in use in the k
Jiri Benc wrote:
On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
Use the stack that's already in the kernel.
Encouraging otherwise hinders continued wireless progress under Linux.
There is nothing like a "802.11 stack" currently in the kernel,
regardless what James Ketrenos is saying
On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
> Use the stack that's already in the kernel.
>
> Encouraging otherwise hinders continued wireless progress under Linux.
There is nothing like a "802.11 stack" currently in the kernel,
regardless what James Ketrenos is saying. Sorry.
--
Ji
Michael Renzmann wrote:
Hi.
On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
Why yet another attempt to write 802.11 stack? Sure, the one currently
in the kernel is unusable and everybody knows about it. But why not to
improve code opensourced by Devicescape some time ago instead of
inventi
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again and again? Yes, I know that code is not
> perfect and nee
Hi.
On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again a
On Sun, 04 Dec 2005 19:50:08 +0100, [EMAIL PROTECTED] wrote:
> The team is in the progress of writing a SoftwareMAC layer,
> which is needed for the bcm device. The SoftMAC is still very
> incomplete. So do not expect to do any fancy stuff like WPA
> or something line that with it.
Why yet another
43 matches
Mail list logo
