Stack
=====
Is the in-kernel stack up-to-date w/ SourceForge? No. Why not?
Can this development be brought into wireless development kernels?
Can the in-kernel stack be saved? With the addition of softmac?
Is it possible to extend softmac to support virtual wlan devices?
If not, how do we proceed?
How do we get more drivers in-kernel? (Multiple stacks probably
don't help beyond the short-term timeframe.)
I think we need to rally as many driver writers as possible a) to
get into the kernel now; and, b) move away from duplicating stack
features. I don't see how to achieve that with the DeviceScape stack
in the short- or medium-term timeframe. I get the impression that
porting drivers from one stack to the other is not all that painful,
particularly in the ieee80211->DeviceScape direction. Is it reasonable
to expect short-term development to stay with the ieee80211 stack,
while planning either a migration to DeviceScape or a major ieee80211
overhaul based on the DeviceScape code?
Do we need to have both wireless-stable and wireless-devel kernels?
What about the suggestion of having both stacks in the kernel at once?
I'm not very excited about two in-kernel stacks. Still, consolidating
wireless drivers down to two stacks is probably better than what we
have now...? Either way, we would have to have general understanding
that at some point (not too far away), one of the stacks would have
to disappear.
--
John W. Linville
[email protected]
On Fri, 2006-01-13 at 17:22 -0500, John W. Linville wrote:
> Can the in-kernel stack be saved? With the addition of softmac?
> Is it possible to extend softmac to support virtual wlan devices?
> If not, how do we proceed?
Well, softmac doesn't really have too many issues [that make it
incompatible with the planned stuff, that is]. Right now it layers
above ieee80211_device, and it would continue doing so, with
ieee80211_device transformed into the representation of the virtual STA
device.
johannes
On Friday 13 January 2006 15:32, John W. Linville wrote:
> Do we need to have both wireless-stable and wireless-devel kernels?
> What about the suggestion of having both stacks in the kernel at once?
> I'm not very excited about two in-kernel stacks. Still, consolidating
> wireless drivers down to two stacks is probably better than what we
> have now...? Either way, we would have to have general understanding
> that at some point (not too far away), one of the stacks would have
> to disappear.
Having not had experience coding for the stacks, I'm not inclined to form an
opinion on which is better. I think on a realistic footing, a stack switch
should only occur if it doesn't come at great expense (unless that great
expense is less than the expense of making the existing stack capable enough
to handle all the devices we want to support).
But I have to NAK the idea of two stacks. There are implications in the 'here
and now', so to speak, but what worries me the most is long term. You know
how it's no fun fixing bugs when you could be adding new features? Let's say
that on May 2006, you drop the hammer and decide that Stack B is the winner.
You've now got to convince / motivate the Stack A users to stop what they're
doing and work hard to migrate to Stack B. There might be stragglers, so
let's say you set a "drop dead date". Now what happens if we reach that date
and some drivers still aren't ready. "Tough," you say, "you've had ample
notice and time to port." Now we've got a flamewar on our hands, because no
one wants to release a new kernel that drops support for things people are
using.
By contrast, if we got softmac in, ieee80211 may still be lacking in some
areas, but if we do the hard work to port a few drivers and get them in-tree
and working well, you start to have happy users. Motivation will build for
others to port and get into the tree (partly because no one wants to be the
odd man out, and their users will probably be frustrated by it too), and part
of the motivation should extend naturally onto improving in-kernel ieee80211
enough to support whatever odd-ball implementations they're dealing with. So
I think you end up with a nice snowball effect.
As an aside to this whole thing, I know we're talking about *kernel* wireless
but it's worthless to most people without good userland support as well.
Anyone have any thoughts and feelings on what things look like on the
desktop? I think if we work closely with some desktop people, we can shepard
in some wonderful new desktop support on top of the new netlink API.
Cheers,
Chase Venters
Chase Venters wrote:
> As an aside to this whole thing, I know we're talking about *kernel* wireless
> but it's worthless to most people without good userland support as well.
> Anyone have any thoughts and feelings on what things look like on the
> desktop? I think if we work closely with some desktop people, we can shepard
> in some wonderful new desktop support on top of the new netlink API.
>
An obvious place to start is the NetworkManager project. They should be
asked the obvious "what do you need" and "does this provide it"
questions. Dan Williams has been active recently producing small kernel
patches which make the kernel side stuff work better with NM, so he
might be a good contact to start with.
Cheers,
Simon.
On Saturday 14 January 2006 00:03, you wrote:
> As an aside to this whole thing, I know we're talking about *kernel* wireless
> but it's worthless to most people without good userland support as well.
> Anyone have any thoughts and feelings on what things look like on the
> desktop? I think if we work closely with some desktop people, we can shepard
> in some wonderful new desktop support on top of the new netlink API.
I am in the KDE development and have (almost) full access to the KDE svn
repository. Altought I did not do much coding on KDE apps recently,
I will be able to help in WiFi support for KDE.
The first thing I thought of, was a tray icon with basic information
about the available interfaces and basic configuration
capabilities.
--
Greetings Michael.
On Fri, 13 Jan 2006, John W. Linville wrote:
> Can the in-kernel stack be saved? With the addition of softmac?
> Is it possible to extend softmac to support virtual wlan devices?
> If not, how do we proceed?
I don't think, that we can continue with the current model of the
stacks. There appears a great variance in the HOST-device
interfaces between WLAN devices of several vendors. The other
problem is, that there is a difference depending on the bus the
device is connected to. Register accesses in USB devices should be
able to sleep. However the 80211 stacks I've seen so far have a
fixed set of capabilities and do also assume, that at the driver
layer everything can be done in atomic mode, which is only true
for buses that support memory-mapping.
In my point of view each stack layer must allow drivers to
overwrite all entry-functions. Drivers could then do
cherry-picking of the provided standard-functions. This is of
course the library approach. The discussion about multiple
stacks will then be muted, because we would have several stacks in
the kernel and on the devices, which would have compatible interfaces.
> Do we need to have both wireless-stable and wireless-devel kernels?
> What about the suggestion of having both stacks in the kernel at once?
> I'm not very excited about two in-kernel stacks. Still, consolidating
> wireless drivers down to two stacks is probably better than what we
> have now...? Either way, we would have to have general understanding
> that at some point (not too far away), one of the stacks would have
> to disappear.
See above.
--
Ulrich Kunitz - [email protected]
On Sat, 2006-01-14 at 10:46 +0000, Simon Kelley wrote:
> Chase Venters wrote:
>
> > As an aside to this whole thing, I know we're talking about *kernel* wireless
> > but it's worthless to most people without good userland support as well.
> > Anyone have any thoughts and feelings on what things look like on the
> > desktop? I think if we work closely with some desktop people, we can shepard
> > in some wonderful new desktop support on top of the new netlink API.
> >
>
> An obvious place to start is the NetworkManager project. They should be
> asked the obvious "what do you need" and "does this provide it"
> questions. Dan Williams has been active recently producing small kernel
> patches which make the kernel side stuff work better with NM, so he
> might be a good contact to start with.
We are actually moving NM on top of wpa_supplicant for the actual
connection process. So essentially, while NM does talk to the card for
information and scanning, wpa_supplicant provides the bulk of the actual
connection process control. Any card that works with wpa_supplicant
should then work with NetworkManager.
Novel's is working on a KDE applet for NM which should hit CVS soon, I
think.
Dan
On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz <[email protected]> wrote:
> [...] Register accesses in USB devices should be
> able to sleep. However the 80211 stacks I've seen so far have a
> fixed set of capabilities and do also assume, that at the driver
> layer everything can be done in atomic mode, which is only true
> for buses that support memory-mapping.
If this problem is real, then it's serious. However, I'm not seeing it
with prism54usb and Berg's softmac (yet?). Would you be so kind to provide
the file name and function name for the code which makes these assumptions?
Thanks,
-- Pete
On Sat, 14 Jan 2006, Pete Zaitcev wrote:
> On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz <[email protected]> wrote:
>
> > [...] Register accesses in USB devices should be
> > able to sleep. However the 80211 stacks I've seen so far have a
> > fixed set of capabilities and do also assume, that at the driver
> > layer everything can be done in atomic mode, which is only true
> > for buses that support memory-mapping.
>
> If this problem is real, then it's serious. However, I'm not seeing it
> with prism54usb and Berg's softmac (yet?). Would you be so kind to provide
> the file name and function name for the code which makes these assumptions?
>
> Thanks,
> -- Pete
>
Pete,
I've been wrong.
I couldn't find the problem in the latest version of the
ieee80211softmac. Thank you for noticing me.
Uli
--
Ulrich Kunitz - [email protected]
On Sat, Jan 14, 2006 at 02:51:14PM +0100, Michael Buesch wrote:
> On Saturday 14 January 2006 00:03, you wrote:
> > As an aside to this whole thing, I know we're talking about *kernel* wireless
> > but it's worthless to most people without good userland support as well.
> > Anyone have any thoughts and feelings on what things look like on the
> > desktop? I think if we work closely with some desktop people, we can shepard
> > in some wonderful new desktop support on top of the new netlink API.
>
> I am in the KDE development and have (almost) full access to the KDE svn
> repository. Altought I did not do much coding on KDE apps recently,
> I will be able to help in WiFi support for KDE.
> The first thing I thought of, was a tray icon with basic information
> about the available interfaces and basic configuration
> capabilities.
There is already at least 2 KDE applications for WiFi stuff,
and both are fully fledged (i.e. not just a signal meter) :
http://websvn.kde.org/trunk/KDE/kdenetwork/wifi/
http://websvn.kde.org/trunk/kdenonbeta/kifi/
Note that I've used neither, so I don't know how good they are
and what features are missing. If you decide to write another apps,
please send me the link so I can add it on my web page.
> Greetings Michael.
Have fun...
Jean