* wireless: recap of current issues (intro)
From: John W. Linville @ 2006-01-13 21:26 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, Jiri Benc, Stefan Rompf, Mike Kershaw,
Krzysztof Halasa, Robert Hancock, Alistair John Strachan,
Dominik Brodowski, Denis Vlasenko, Danny van Dyk,
Stephen Hemminger, feyd, Chase Venters, Andreas Mohr,
Bas Vermeulen, Jean Tourrilhes, Daniel Drake, Ulrich Kunitz,
Phil Dibowitz, Simon Kelley, Michael Buesch, Marcel Holtmann,
Patrick McHardy, Ingo Oeser
In-Reply-To: <20060113195723.GB16166@tuxdriver.com>
My original post got eaten by the lists -- probably too big...
I'm reposting in sections. After this intro follow sections on
Configuration, Compatibility, Stack, Other Issues, and Actions.
Enjoy! :-)
---
WiFi-ers...
Here I am, still feeling "up to the challenge"... I have stopped
hyper-ventilating and the nervous vomiting is all over... :-)
Having accepted the wireless role, I wanted to review the discussions
prompted by Jeff's "State of the Union" message from a little over a
week ago. There is lots of good talent involved in these discussions,
and I believe a surprisingly high level of agreement (some of it
nearly violent!) amongst the players.
Below I have recapped what I saw as most of the important issues.
I have endorsed some of the ideas, mostly those which seem to have
broad agreement. I have also thrown-out a few ideas of my own.
Please do comment on all of them, as neither my summaries nor my
original ideas are likely to be without fault. :-)
I have primarily grouped the issues into configuration, compatibility,
and stack concerns. I also included an "other" group for a few other
concerns that I though were worth mentioning.
Finally, I have included an "actions" section to reveal some of my
near-term plans and some of what I am thinking about beyond that.
I would love to hear any comments you might have on these items
as well.
Thanks for taking the time to look this over. Creating this recap
has reinforced one thing: this is far too big for just a single person
(or even a small group) to tackle alone!
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* wireless: recap of current issues (configuration)
From: John W. Linville @ 2006-01-13 22:19 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113213011.GE16166@tuxdriver.com>
Configuration
=============
Configuration seems to be coalescing around netlink. Among other
things, this technology provides for muliticast requests and
asynchronous event notification.
The kernel should provide generic handlers for netlink
configuraion messages, and there should be a per-device 80211_ops
(wireless_ops? akin to ethtool_ops) structure for drivers to
populate appropriately.
At init, physical devices should be represented by a "WiPHY" device,
not directly by a net_device. The list of physical devices should
be discoverable through netlink and/or sysfs. (A WiPHY device is an
abstraction representing the radio interface itself.)
Virtual wlan devices should be associated to a WiPHY device many-to-one
(one-to-one for some devices). Virtual devices correspond to a net_device.
Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
raw?, other modes?) which defines its "on the air" behaviour. Should
this mode be fixed when the wlan device is created? Or something
that can be changed when the net_device is down?
It may be necessary to remove, suspend, and/or disable wlan devices
in order to add, resume, and/or enable other types of wlan devices
on the same WiPHY device (especialy true for rfmon). A mechanism is
needed for drivers to be able to influence or disallow combinations
of wlan devices in accordance with capabilities of the hardware.
Do "global" config requests go to any associated wlan device?
Or must they be directed to the WiPHY device? Does it matter?
I think we should require "global" configuration to target the WiPHY
device, while "local" configuration remains with the wlan device.
(I'm not sure how important this point is?) Either way, the WiPHY
device will need some way to be able to reject configuration requests
that are incompatible among its associated wlan devices. Since the
wlan interface implementations should not be device specific, perhaps
the 802.11 stack can be smart enough to filter-out most conflicting
config requests before they get to the WiPHY device?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* wireless: recap of current issues (compatibility)
From: John W. Linville @ 2006-01-13 22:20 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113213126.GF16166@tuxdriver.com>
Compatibility
=============
The netlink configuration mechanism needs compatibility code to
translate wireless extension ioctls into netlink transactions.
We need to be an 802.11 stack (i.e. drivers need to handle 802.11
frames). Ethernet emulation is bound to paint us into a corner
eventually (if it hasn't already).
We need an ethernet<->802.11 translational bridging interface for
compatibility, and to enable 802.1 bridging with ethernet. This could
be a configuration setting for a wlan interface. It might be limited
to wlan interfaces in station (or WDS) mode?
802.11 framing may break older protocols (e.g. DECnet). I don't
see this as a big problem, as I imagine such installations aren't
rolling-out lots of WiFi...if I'm wrong, will the translational
bridging code resolve this issue?
Should a default wlan device be created at WiPHY init? Should it
enable translational bridging? I'm inclined against this, but is it
worthwhile for compatibility? Could/should this be a configuration
option for the stack?
How about if WiPHY initialization triggered a netlink broadcast?
Then a daemon could monitor those broadcasts and create whatever wlan
devices (ethernet emulation, rfmon, none at all) that the daemon was
configured to create. How would this effect modprobe behaviour?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* wireless: recap of current issues (stack)
From: John W. Linville @ 2006-01-13 22:22 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113213200.GG16166@tuxdriver.com>
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
linville@tuxdriver.com
^ permalink raw reply
* wireless: recap of current issues (other issues)
From: John W. Linville @ 2006-01-13 22:24 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113213237.GH16166@tuxdriver.com>
Other Issues
============
Radiotap headers make sense for an rfmon virtual device. I don't
think it makes sense for "normal" usage. Should there be an option
for radiotap headers on non-rfmon links?
Rfmon interferes w/ other interfaces, but may be handy to enter/leave
w/ little effort. Perhaps a config option for physical device to
suspend/resume all (non-rfmon) virtual devices before/after enabling
rfmon virtual device? (Would multiple rfmon devices even make sense?
If not, is it worth restricting that?)
What about old hardware w/ inactive maintenance? Deprecate/remove?
Grandfather them w/ treatment as ethernet devices? Probably don't
need a pronouncement on this at this time...
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* wireless: recap of current issues (actions)
From: John W. Linville @ 2006-01-13 22:25 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113213311.GI16166@tuxdriver.com>
Actions
=======
I need to establish a public git tree for wireless. I would like for
this to be on kernel.org, but I haven't got an account established
there yet. I've been dragging my feet a little, hoping that the
kernel.org account would materialize.
I intend to get the sipsolutions softmac code into the wireless
development kernels ASAP. I hope this will spur driver writers that
need this functionality to start consolidating on the in-kernel stack.
Obviously, what to do with the DeviceScape stack is a pressing issue.
I am open to taking patches to introduce the DeviceScape stack on a
branch under the (still coming) wireless tree. Obviously, patches
that bring features from the DeviceScape stack to the ieee80211 stack
would be generally welcome.
Since we are toying with the issue of multiple stacks (at least in the
wireless development kernels), some thought needs to be done w.r.t. how
to make a final decision between the two stacks. An objective lists
of functional feature requirements seems like a good place to start.
IOW, I would like to have a list of features that would trigger the
removal of one stack shortly after the other stack achieves support
for the list. Is this feasible?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Johannes Berg @ 2006-01-13 22:32 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113221935.GJ16166@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]
[since none our replies made it to the lists, here mine are again.
apologies to those who see it twice, just skip it, I only pasted my
previous replies]
> Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
> raw?, other modes?) which defines its "on the air" behaviour. Should
> this mode be fixed when the wlan device is created? Or something
> that can be changed when the net_device is down?
IMHO there's not much point in allowing changes. I have a feeling that
might create icky issues you don't want to have to tackle when the
solution is easy by just not allowing it. Part of my thinking is that
different virtual types have different structures associated, so
changing it needs re-creating structures anyway. And different virtual
device types might even be provided by different kernel modules so you
don't carry around AP mode if you don't need it.
> Do "global" config requests go to any associated wlan device?
> Or must they be directed to the WiPHY device? Does it matter?
> I think we should require "global" configuration to target the WiPHY
> device, while "local" configuration remains with the wlan device.
> (I'm not sure how important this point is?)
Right [global config targets wiphy]. I do think this is an important UI
issue that userspace will have to tackle, but I think the correct way
for the kernel is to surface this issue instead of creating workarounds.
> Either way, the WiPHY
> device will need some way to be able to reject configuration requests
> that are incompatible among its associated wlan devices. Since the
> wlan interface implementations should not be device specific, perhaps
> the 802.11 stack can be smart enough to filter-out most conflicting
> config requests before they get to the WiPHY device?
I'm not sure this is worth it. While putting this into the WiPHY device
creates more logic there, putting knowledge like 'how many different
channels can this WiPHY device support' etc. into some representation
that can be used by the stack to decide is much more trouble than it is
worth.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (compatibility)
From: Johannes Berg @ 2006-01-13 22:33 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113222054.GK16166@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
> The netlink configuration mechanism needs compatibility code to
> translate wireless extension ioctls into netlink transactions.
I think we could restrict this to allow ioctl configuration only if
there's just a single active virtual dev [excluding some special cases
like changing the mode which would (see above) require deactivating one
and activating another virtual dev. or is that not possible without
screwing up naming etc? that might get tricky if we disallow mode
changing, but can probably be worked around easier than allowing mode
changing, especially since this is to be deprecated]
> Should a default wlan device be created at WiPHY init? Should it
> enable translational bridging? I'm inclined against this, but is it
> worthwhile for compatibility? Could/should this be a configuration
> option for the stack?
If you want the old userspace API to 'just work' you have to create one
default wlan device at WiPHY init.
> How about if WiPHY initialization triggered a netlink broadcast?
It definitely should, in any case.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH] [NETFILTER] x_tables
From: David S. Miller @ 2006-01-13 22:33 UTC (permalink / raw)
To: laforge; +Cc: netdev, netfilter-devel
In-Reply-To: <20060112204734.GQ4430@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Thu, 12 Jan 2006 21:47:34 +0100
> Finally, I included all the suggestions/comments for x_tables "take 5",
> ran the nfsim testsuite and feel confident that this is ready for prime
> time.
>
> Please apply this huge one for 2.6.16,
It's been in my tree since last night, I'll try to see if
I can get Linus to eat this along with TIPC which are the
last two major things I plan to try and merge.
Let's get into bug fix mode people...
^ permalink raw reply
* Re: wireless: recap of current issues (stack)
From: Johannes Berg @ 2006-01-13 22:34 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113222259.GL16166@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (other issues)
From: Johannes Berg @ 2006-01-13 22:35 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113222408.GM16166@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]
On Fri, 2006-01-13 at 17:24 -0500, John W. Linville wrote:
> Radiotap headers make sense for an rfmon virtual device. I don't
> think it makes sense for "normal" usage. Should there be an option
> for radiotap headers on non-rfmon links?
Yes. For hardware debugging.
> Rfmon interferes w/ other interfaces, but may be handy to enter/leave
> w/ little effort. Perhaps a config option for physical device to
> suspend/resume all (non-rfmon) virtual devices before/after enabling
> rfmon virtual device? (Would multiple rfmon devices even make sense?
> If not, is it worth restricting that?)
Multiple rfmon devices make sense in hypothetical or future hardware if
different channels are supported on one WiPHY at once, but the rfmon
device shall be restricted to a single one. Since we probably need a way
to deactivate virtual devices anyway, having a config option to
suspend/resume all others doesn't make sense -- userspace programs can
just as well cycle over them and do it themselves.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (actions)
From: Johannes Berg @ 2006-01-13 22:36 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113222512.GN16166@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
On Fri, 2006-01-13 at 17:25 -0500, John W. Linville wrote:
> Since we are toying with the issue of multiple stacks (at least in the
> wireless development kernels), some thought needs to be done w.r.t. how
> to make a final decision between the two stacks. An objective lists
> of functional feature requirements seems like a good place to start.
> IOW, I would like to have a list of features that would trigger the
> removal of one stack shortly after the other stack achieves support
> for the list. Is this feasible?
I started collecting some info on
http://johannes.sipsolutions.net/802.11_stacks
That page should probably be moved somewhere (netdev wiki?) where it is
writable by others. I also need to update it to include comments by Jean
Tourrilhes.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues
From: Ben Greear @ 2006-01-13 22:49 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <43C80F9A.8020203@candelatech.com>
This is a re-send since the lists ate my reply. I've also
trimmed out all but netdev and lkml email addresses.
> Do "global" config requests go to any associated wlan device?
> Or must they be directed to the WiPHY device? Does it matter?
> I think we should require "global" configuration to target the WiPHY
> device, while "local" configuration remains with the wlan device.
> (I'm not sure how important this point is?) Either way, the WiPHY
> device will need some way to be able to reject configuration requests
> that are incompatible among its associated wlan devices. Since the
> wlan interface implementations should not be device specific, perhaps
> the 802.11 stack can be smart enough to filter-out most conflicting
> config requests before they get to the WiPHY device?
I'd create a generic function that handles most things, but allow the
driver to over-ride this method if it knows better. Something like
is_ok_to_add(new wlan device info);
might need an is_ok_to_remove(foo); as well.
> We need an ethernet<->802.11 translational bridging interface for
> compatibility, and to enable 802.1 bridging with ethernet. This could
> be a configuration setting for a wlan interface. It might be limited
> to wlan interfaces in station (or WDS) mode?
If we can send a raw ethernet frame at the driver/stack, then it can
reject or send as needed. For instance, you should be able to 'bridge'
to a regular station interface _IF_ the source MAC matches the station's
source MAC. This would also allow the packet-socket code to work with
wifi just like it does with wired ethernet (and 802.1Q VLANs, for that matter.)
> Should a default wlan device be created at WiPHY init? Should it
> enable translational bridging? I'm inclined against this, but is it
> worthwhile for compatibility? Could/should this be a configuration
> option for the stack?
I wouldn't...can't see how it helps anything.
> 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.)
One thing multiple in-kernel stacks might give us would be an easier way for
developers (especially those not fully versed in wifi)
to try out features of both stacks and make merging between
the stacks easier (with the goal of having only one stack). It would probably
allow more drivers to get in immediately as well, which should get
more developers working on the same core logic.
> Other Issues
> ============
>
> Radiotap headers make sense for an rfmon virtual device. I don't
> think it makes sense for "normal" usage. Should there be an option
> for radiotap headers on non-rfmon links?
>
> Rfmon interferes w/ other interfaces, but may be handy to enter/leave
> w/ little effort. Perhaps a config option for physical device to
> suspend/resume all (non-rfmon) virtual devices before/after enabling
> rfmon virtual device? (Would multiple rfmon devices even make sense?
> If not, is it worth restricting that?)
With regard to conflicting virtual devices: How about treat all 'DOWN'
devices as irrelevent to the physical device. That way, you can have
rfmon, AP, station, etc devices all configured at once, and just ifdown/ifup
the one(s) you want to use at any given point. The virtual interfaces can
keep all config info needed to bring themselves back online.
> What about old hardware w/ inactive maintenance? Deprecate/remove?
> Grandfather them w/ treatment as ethernet devices? Probably don't
> need a pronouncement on this at this time...
Ignore for now..maybe it will get more active maintenance when the
stack solidifies enough to make developing wifi less complex.
> Since we are toying with the issue of multiple stacks (at least in the
> wireless development kernels), some thought needs to be done w.r.t. how
> to make a final decision between the two stacks. An objective lists
> of functional feature requirements seems like a good place to start.
> IOW, I would like to have a list of features that would trigger the
> removal of one stack shortly after the other stack achieves support
> for the list. Is this feasible?
Would it be possible to write a very thin 'shim' stack that could
sit over either device-scape or the current stack? This shim could
start solidifying the API with user-space somewhat independently of
the lower levels. If one stack did not support a particular feature,
then it just returns a failure code. If this is not too much work,
it might allow the stack merge to happen gradually. Of course, this
might be more work than it's worth...
Thanks for all the work you're doing!
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: wireless: recap of current issues (other issues)
From: Johannes Berg @ 2006-01-13 23:02 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <1137191711.2520.69.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
On Fri, 2006-01-13 at 23:35 +0100, Johannes Berg wrote:
> On Fri, 2006-01-13 at 17:24 -0500, John W. Linville wrote:
>
> > Radiotap headers make sense for an rfmon virtual device. I don't
> > think it makes sense for "normal" usage. Should there be an option
> > for radiotap headers on non-rfmon links?
>
> Yes. For hardware debugging.
Actually, scratch that. For hardware debugging you just add a virtual
rfmon device and go with that, and just don't do anything except 2
virtual devices on the wiphy.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (stack)
From: Chase Venters @ 2006-01-13 23:03 UTC (permalink / raw)
To: netdev, linux-kernel, Jiri Benc, Stefan Rompf, Mike Kershaw,
Krzysztof Halasa, Robert Hancock, Alistair John Strachan,
Dominik Brodowski, Denis Vlasenko, Danny van Dyk,
Stephen Hemminger, feyd, Andreas Mohr, Bas Vermeulen,
Jean Tourrilhes, Daniel Drake, Ulrich Kunitz, Phil Dibowitz,
Simon Kelley, Michael Buesch, Marcel Holtmann, Patrick McHardy,
Ingo Oeser, Harald Welte <laforg
In-Reply-To: <20060113213200.GG16166@tuxdriver.com>
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
^ permalink raw reply
* Re: WCONF, netlink based WE replacement.
From: Pavel Machek @ 2006-01-13 23:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Michael Buesch, linux-kernel, netdev
In-Reply-To: <20060113095533.5d5df015@dxpl.pdx.osdl.net>
On Pá 13-01-06 09:55:33, Stephen Hemminger wrote:
> On Thu, 12 Jan 2006 18:24:02 +0100
>
> 4. What about non-ieee80211 devices? With the growth of (mostly proprietary)
> cell phone carrier wireless, you don't want to shut out that.
Don't mix it here. Mobile phones normally talk using AT interface,
modem-like.
Pavel
--
Thanks, Sharp!
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Krzysztof Halasa @ 2006-01-14 0:05 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113221935.GJ16166@tuxdriver.com>
"John W. Linville" <linville@tuxdriver.com> writes:
> Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
> raw?, other modes?) which defines its "on the air" behaviour. Should
> this mode be fixed when the wlan device is created?
I think so. If needed one can delete and create.
> Or something
> that can be changed when the net_device is down?
IMHO: unnecessary complicates things.
> It may be necessary to remove, suspend, and/or disable wlan devices
> in order to add, resume, and/or enable other types of wlan devices
> on the same WiPHY device (especialy true for rfmon). A mechanism is
> needed for drivers to be able to influence or disallow combinations
> of wlan devices in accordance with capabilities of the hardware.
If the control messages go through the main (WiPHY) driver it can
decide and/or forward the request further, to the library.
Not sure about netlink. OTOH I'm at all not sure netlink should be
used for configuration. sysfs, ioctl seem a better options. Netlink
is better for state monitoring etc. I don't know it very well though.
> Do "global" config requests go to any associated wlan device?
Are they any global config settings?
sysctl or sysfs maybe?
> Or must they be directed to the WiPHY device? Does it matter?
If you mean "settings for a particular physical card" then WiPHY.
> I think we should require "global" configuration to target the WiPHY
> device, while "local" configuration remains with the wlan device.
If "local" means "concerning the wlan device" then sure, yes.
> (I'm not sure how important this point is?) Either way, the WiPHY
> device will need some way to be able to reject configuration requests
> that are incompatible among its associated wlan devices. Since the
> wlan interface implementations should not be device specific, perhaps
> the 802.11 stack can be smart enough to filter-out most conflicting
> config requests before they get to the WiPHY device?
I don't think so. The hardware driver should get the request first,
the rest should look like a library.
I've played with both approaches for years and I would avoid
"802.11 using the hw driver" scenario if at all possible.
--
Krzysztof Halasa
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-14 1:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-kernel
In-Reply-To: <1137191522.2520.63.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]
On Fri, Jan 13, 2006 at 11:32:02PM +0100, Johannes Berg wrote:
> I'm not sure this is worth it. While putting this into the WiPHY device
> creates more logic there, putting knowledge like 'how many different
> channels can this WiPHY device support' etc. into some representation
> that can be used by the stack to decide is much more trouble than it is
> worth.
Do you mean 'simultaneous' channel operation, or something more mundane
like simply 'what frequencies can I run on'?
If you're talking about the former.. things get quite complicated, but
that could be handled by having two WiPHY devices registered.
As for the latter, when you factor in the needs of 802.11d and its
dependents (802.11j, 802.11k, and others) the stack is going to need to
be aware of the available channel sets; both in the sense of hardware
support and also the various regulatory requirements.
The hardware knows what frequencies it supports. Unfortunately this has
to be a somewhat dynamic thing, as this is often not queryable until the
device firmware is up and running.
This can be accomplished by passing a static table to the
register_wiphy_device() call (or perhaps via a struct wiphy_dev
parameter) or through a more explicit, dynamic interface like:
wiphy_register_supported_frequency(hw, 2412).
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [2.6 patch] drivers/net/wireless/hostap/hostap_main.c shouldn't #include C files
From: Adrian Bunk @ 2006-01-14 2:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: jkmaline, hostap, linux-kernel, netdev
This patch contains an attempt to properly build hostap.o without
#include'ing C files.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 5 Jan 2006
drivers/net/wireless/hostap/Makefile | 3
drivers/net/wireless/hostap/hostap.h | 37 +++++++++++
drivers/net/wireless/hostap/hostap_80211.h | 3
drivers/net/wireless/hostap/hostap_80211_rx.c | 11 +++
drivers/net/wireless/hostap/hostap_80211_tx.c | 15 ++++
drivers/net/wireless/hostap/hostap_ap.c | 36 ++++++----
drivers/net/wireless/hostap/hostap_ap.h | 2
drivers/net/wireless/hostap/hostap_common.h | 3
drivers/net/wireless/hostap/hostap_info.c | 3
drivers/net/wireless/hostap/hostap_ioctl.c | 12 ++-
drivers/net/wireless/hostap/hostap_main.c | 60 +-----------------
drivers/net/wireless/hostap/hostap_proc.c | 8 ++
drivers/net/wireless/hostap/hostap_wlan.h | 4 +
include/net/ieee80211_crypt.h | 1
14 files changed, 120 insertions(+), 78 deletions(-)
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/Makefile.old 2005-12-03 00:40:33.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/Makefile 2005-12-03 00:49:47.000000000 +0100
@@ -1,4 +1,5 @@
-hostap-y := hostap_main.o
+hostap-y := hostap_80211_rx.o hostap_80211_tx.o hostap_ap.o hostap_info.o \
+ hostap_ioctl.o hostap_main.o hostap_proc.o
obj-$(CONFIG_HOSTAP) += hostap.o
obj-$(CONFIG_HOSTAP_CS) += hostap_cs.o
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap.h.old 2005-12-03 00:41:48.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap.h 2005-12-03 02:37:21.000000000 +0100
@@ -1,6 +1,15 @@
#ifndef HOSTAP_H
#define HOSTAP_H
+#include <linux/ethtool.h>
+
+#include "hostap_wlan.h"
+#include "hostap_ap.h"
+
+static const long freq_list[] = { 2412, 2417, 2422, 2427, 2432, 2437, 2442,
+ 2447, 2452, 2457, 2462, 2467, 2472, 2484 };
+#define FREQ_COUNT (sizeof(freq_list) / sizeof(freq_list[0]))
+
/* hostap.c */
extern struct proc_dir_entry *hostap_proc;
@@ -40,6 +49,26 @@
int prism2_sta_send_mgmt(local_info_t *local, u8 *dst, u16 stype,
u8 *body, size_t bodylen);
int prism2_sta_deauth(local_info_t *local, u16 reason);
+int prism2_wds_add(local_info_t *local, u8 *remote_addr,
+ int rtnl_locked);
+int prism2_wds_del(local_info_t *local, u8 *remote_addr,
+ int rtnl_locked, int do_not_remove);
+
+
+/* hostap_ap.c */
+
+int ap_control_add_mac(struct mac_restrictions *mac_restrictions, u8 *mac);
+int ap_control_del_mac(struct mac_restrictions *mac_restrictions, u8 *mac);
+void ap_control_flush_macs(struct mac_restrictions *mac_restrictions);
+int ap_control_kick_mac(struct ap_data *ap, struct net_device *dev, u8 *mac);
+void ap_control_kickall(struct ap_data *ap);
+void * ap_crypt_get_ptrs(struct ap_data *ap, u8 *addr, int permanent,
+ struct ieee80211_crypt_data ***crypt);
+int prism2_ap_get_sta_qual(local_info_t *local, struct sockaddr addr[],
+ struct iw_quality qual[], int buf_size,
+ int aplist);
+int prism2_ap_translate_scan(struct net_device *dev, char *buffer);
+int prism2_hostapd(struct ap_data *ap, struct prism2_hostapd_param *param);
/* hostap_proc.c */
@@ -54,4 +83,12 @@
void hostap_info_process(local_info_t *local, struct sk_buff *skb);
+/* hostap_ioctl.c */
+
+extern const struct iw_handler_def hostap_iw_handler_def;
+extern struct ethtool_ops prism2_ethtool_ops;
+
+int hostap_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd);
+
+
#endif /* HOSTAP_H */
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_common.h.old 2005-12-03 01:19:43.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_common.h 2005-12-03 01:21:13.000000000 +0100
@@ -1,6 +1,9 @@
#ifndef HOSTAP_COMMON_H
#define HOSTAP_COMMON_H
+#include <linux/types.h>
+#include <linux/if_ether.h>
+
#define BIT(x) (1 << (x))
#define MAC2STR(a) (a)[0], (a)[1], (a)[2], (a)[3], (a)[4], (a)[5]
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_wlan.h.old 2005-12-03 01:22:53.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_wlan.h 2005-12-03 01:26:43.000000000 +0100
@@ -1,6 +1,10 @@
#ifndef HOSTAP_WLAN_H
#define HOSTAP_WLAN_H
+#include <linux/wireless.h>
+#include <linux/netdevice.h>
+#include <net/iw_handler.h>
+
#include "hostap_config.h"
#include "hostap_common.h"
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_ap.h.old 2005-12-03 01:28:46.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_ap.h 2005-12-03 01:29:01.000000000 +0100
@@ -1,6 +1,8 @@
#ifndef HOSTAP_AP_H
#define HOSTAP_AP_H
+#include "hostap_80211.h"
+
/* AP data structures for STAs */
/* maximum number of frames to buffer per STA */
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_80211.h.old 2005-12-03 01:07:18.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_80211.h 2005-12-03 01:11:00.000000000 +0100
@@ -1,6 +1,9 @@
#ifndef HOSTAP_80211_H
#define HOSTAP_80211_H
+#include <linux/types.h>
+#include <net/ieee80211_crypt.h>
+
struct hostap_ieee80211_mgmt {
u16 frame_control;
u16 duration;
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_main.c.old 2005-12-03 00:40:11.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_main.c 2005-12-03 02:24:34.000000000 +0100
@@ -24,6 +24,7 @@
#include <linux/kmod.h>
#include <linux/rtnetlink.h>
#include <linux/wireless.h>
+#include <linux/etherdevice.h>
#include <net/iw_handler.h>
#include <net/ieee80211.h>
#include <net/ieee80211_crypt.h>
@@ -47,57 +48,6 @@
#define PRISM2_MAX_MTU (PRISM2_MAX_FRAME_SIZE - (6 /* LLC */ + 8 /* WEP */))
-/* hostap.c */
-static int prism2_wds_add(local_info_t *local, u8 *remote_addr,
- int rtnl_locked);
-static int prism2_wds_del(local_info_t *local, u8 *remote_addr,
- int rtnl_locked, int do_not_remove);
-
-/* hostap_ap.c */
-static int prism2_ap_get_sta_qual(local_info_t *local, struct sockaddr addr[],
- struct iw_quality qual[], int buf_size,
- int aplist);
-static int prism2_ap_translate_scan(struct net_device *dev, char *buffer);
-static int prism2_hostapd(struct ap_data *ap,
- struct prism2_hostapd_param *param);
-static void * ap_crypt_get_ptrs(struct ap_data *ap, u8 *addr, int permanent,
- struct ieee80211_crypt_data ***crypt);
-static void ap_control_kickall(struct ap_data *ap);
-#ifndef PRISM2_NO_KERNEL_IEEE80211_MGMT
-static int ap_control_add_mac(struct mac_restrictions *mac_restrictions,
- u8 *mac);
-static int ap_control_del_mac(struct mac_restrictions *mac_restrictions,
- u8 *mac);
-static void ap_control_flush_macs(struct mac_restrictions *mac_restrictions);
-static int ap_control_kick_mac(struct ap_data *ap, struct net_device *dev,
- u8 *mac);
-#endif /* !PRISM2_NO_KERNEL_IEEE80211_MGMT */
-
-
-static const long freq_list[] = { 2412, 2417, 2422, 2427, 2432, 2437, 2442,
- 2447, 2452, 2457, 2462, 2467, 2472, 2484 };
-#define FREQ_COUNT (sizeof(freq_list) / sizeof(freq_list[0]))
-
-
-/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
-/* Ethernet-II snap header (RFC1042 for most EtherTypes) */
-static unsigned char rfc1042_header[] =
-{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 };
-/* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */
-static unsigned char bridge_tunnel_header[] =
-{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 };
-/* No encapsulation header if EtherType < 0x600 (=length) */
-
-
-/* FIX: these could be compiled separately and linked together to hostap.o */
-#include "hostap_ap.c"
-#include "hostap_info.c"
-#include "hostap_ioctl.c"
-#include "hostap_proc.c"
-#include "hostap_80211_rx.c"
-#include "hostap_80211_tx.c"
-
-
struct net_device * hostap_add_interface(struct local_info *local,
int type, int rtnl_locked,
const char *prefix,
@@ -196,8 +146,8 @@
}
-static int prism2_wds_add(local_info_t *local, u8 *remote_addr,
- int rtnl_locked)
+int prism2_wds_add(local_info_t *local, u8 *remote_addr,
+ int rtnl_locked)
{
struct net_device *dev;
struct list_head *ptr;
@@ -258,8 +208,8 @@
}
-static int prism2_wds_del(local_info_t *local, u8 *remote_addr,
- int rtnl_locked, int do_not_remove)
+int prism2_wds_del(local_info_t *local, u8 *remote_addr,
+ int rtnl_locked, int do_not_remove)
{
unsigned long flags;
struct list_head *ptr;
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_80211_rx.c.old 2005-12-03 00:53:21.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_80211_rx.c 2005-12-03 02:35:11.000000000 +0100
@@ -1,7 +1,18 @@
#include <linux/etherdevice.h>
+#include <net/ieee80211_crypt.h>
#include "hostap_80211.h"
#include "hostap.h"
+#include "hostap_ap.h"
+
+/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
+/* Ethernet-II snap header (RFC1042 for most EtherTypes) */
+static unsigned char rfc1042_header[] =
+{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 };
+/* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */
+static unsigned char bridge_tunnel_header[] =
+{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 };
+/* No encapsulation header if EtherType < 0x600 (=length) */
void hostap_dump_rx_80211(const char *name, struct sk_buff *skb,
struct hostap_80211_rx_status *rx_stats)
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_80211_tx.c.old 2005-12-03 01:05:49.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_80211_tx.c 2005-12-03 02:35:19.000000000 +0100
@@ -1,3 +1,18 @@
+#include "hostap_80211.h"
+#include "hostap_common.h"
+#include "hostap_wlan.h"
+#include "hostap.h"
+#include "hostap_ap.h"
+
+/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
+/* Ethernet-II snap header (RFC1042 for most EtherTypes) */
+static unsigned char rfc1042_header[] =
+{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 };
+/* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */
+static unsigned char bridge_tunnel_header[] =
+{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 };
+/* No encapsulation header if EtherType < 0x600 (=length) */
+
void hostap_dump_tx_80211(const char *name, struct sk_buff *skb)
{
struct ieee80211_hdr_4addr *hdr;
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_ap.c.old 2005-12-03 01:18:28.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_ap.c 2005-12-03 02:21:57.000000000 +0100
@@ -16,6 +16,14 @@
* (8802.11: 5.5)
*/
+#include <linux/proc_fs.h>
+#include <linux/delay.h>
+#include <linux/random.h>
+
+#include "hostap_wlan.h"
+#include "hostap.h"
+#include "hostap_ap.h"
+
static int other_ap_policy[MAX_PARM_DEVICES] = { AP_OTHER_AP_SKIP_ALL,
DEF_INTS };
module_param_array(other_ap_policy, int, NULL, 0444);
@@ -360,8 +368,7 @@
}
-static int ap_control_add_mac(struct mac_restrictions *mac_restrictions,
- u8 *mac)
+int ap_control_add_mac(struct mac_restrictions *mac_restrictions, u8 *mac)
{
struct mac_entry *entry;
@@ -380,8 +387,7 @@
}
-static int ap_control_del_mac(struct mac_restrictions *mac_restrictions,
- u8 *mac)
+int ap_control_del_mac(struct mac_restrictions *mac_restrictions, u8 *mac)
{
struct list_head *ptr;
struct mac_entry *entry;
@@ -433,7 +439,7 @@
}
-static void ap_control_flush_macs(struct mac_restrictions *mac_restrictions)
+void ap_control_flush_macs(struct mac_restrictions *mac_restrictions)
{
struct list_head *ptr, *n;
struct mac_entry *entry;
@@ -454,8 +460,7 @@
}
-static int ap_control_kick_mac(struct ap_data *ap, struct net_device *dev,
- u8 *mac)
+int ap_control_kick_mac(struct ap_data *ap, struct net_device *dev, u8 *mac)
{
struct sta_info *sta;
u16 resp;
@@ -486,7 +491,7 @@
#endif /* PRISM2_NO_KERNEL_IEEE80211_MGMT */
-static void ap_control_kickall(struct ap_data *ap)
+void ap_control_kickall(struct ap_data *ap)
{
struct list_head *ptr, *n;
struct sta_info *sta;
@@ -2321,9 +2326,9 @@
}
-static int prism2_ap_get_sta_qual(local_info_t *local, struct sockaddr addr[],
- struct iw_quality qual[], int buf_size,
- int aplist)
+int prism2_ap_get_sta_qual(local_info_t *local, struct sockaddr addr[],
+ struct iw_quality qual[], int buf_size,
+ int aplist)
{
struct ap_data *ap = local->ap;
struct list_head *ptr;
@@ -2363,7 +2368,7 @@
/* Translate our list of Access Points & Stations to a card independant
* format that the Wireless Tools will understand - Jean II */
-static int prism2_ap_translate_scan(struct net_device *dev, char *buffer)
+int prism2_ap_translate_scan(struct net_device *dev, char *buffer)
{
struct hostap_interface *iface;
local_info_t *local;
@@ -2608,8 +2613,7 @@
}
-static int prism2_hostapd(struct ap_data *ap,
- struct prism2_hostapd_param *param)
+int prism2_hostapd(struct ap_data *ap, struct prism2_hostapd_param *param)
{
switch (param->cmd) {
case PRISM2_HOSTAPD_FLUSH:
@@ -3207,8 +3211,8 @@
}
-static void * ap_crypt_get_ptrs(struct ap_data *ap, u8 *addr, int permanent,
- struct ieee80211_crypt_data ***crypt)
+void * ap_crypt_get_ptrs(struct ap_data *ap, u8 *addr, int permanent,
+ struct ieee80211_crypt_data ***crypt)
{
struct sta_info *sta;
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_info.c.old 2005-12-03 01:49:24.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_info.c 2005-12-03 01:51:43.000000000 +0100
@@ -1,5 +1,8 @@
/* Host AP driver Info Frame processing (part of hostap.o module) */
+#include "hostap_wlan.h"
+#include "hostap.h"
+#include "hostap_ap.h"
/* Called only as a tasklet (software IRQ) */
static void prism2_info_commtallies16(local_info_t *local, unsigned char *buf,
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_ioctl.c.old 2005-12-03 01:52:34.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_ioctl.c 2005-12-03 02:27:09.000000000 +0100
@@ -1,11 +1,13 @@
/* ioctl() (mostly Linux Wireless Extensions) routines for Host AP driver */
-#ifdef in_atomic
-/* Get kernel_locked() for in_atomic() */
+#include <linux/types.h>
#include <linux/smp_lock.h>
-#endif
#include <linux/ethtool.h>
+#include <net/ieee80211_crypt.h>
+#include "hostap_wlan.h"
+#include "hostap.h"
+#include "hostap_ap.h"
static struct iw_statistics *hostap_get_wireless_stats(struct net_device *dev)
{
@@ -3910,7 +3912,7 @@
local->sta_fw_ver & 0xff);
}
-static struct ethtool_ops prism2_ethtool_ops = {
+struct ethtool_ops prism2_ethtool_ops = {
.get_drvinfo = prism2_get_drvinfo
};
@@ -3985,7 +3987,7 @@
(iw_handler) prism2_ioctl_priv_readmif, /* 3 */
};
-static const struct iw_handler_def hostap_iw_handler_def =
+const struct iw_handler_def hostap_iw_handler_def =
{
.num_standard = sizeof(prism2_handler) / sizeof(iw_handler),
.num_private = sizeof(prism2_private_handler) / sizeof(iw_handler),
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_proc.c.old 2005-12-03 02:29:08.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_proc.c 2005-12-03 02:32:00.000000000 +0100
@@ -1,5 +1,12 @@
/* /proc routines for Host AP driver */
+#include <linux/types.h>
+#include <linux/proc_fs.h>
+#include <net/ieee80211_crypt.h>
+
+#include "hostap_wlan.h"
+#include "hostap.h"
+
#define PROC_LIMIT (PAGE_SIZE - 80)
--- linux-2.6.15-mm1-full/include/net/ieee80211_crypt.h.old 2006-01-05 22:28:09.000000000 +0100
+++ linux-2.6.15-mm1-full/include/net/ieee80211_crypt.h 2006-01-05 22:28:26.000000000 +0100
@@ -25,6 +25,7 @@
#include <linux/types.h>
#include <linux/list.h>
+#include <net/ieee80211.h>
#include <asm/atomic.h>
enum {
^ permalink raw reply
* [2.6 patch] drivers/net/s2io.c: make code static
From: Adrian Bunk @ 2006-01-14 2:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: Raghavendra Koushik, jgarzik, netdev, linux-kernel
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 5 Jan 2006
drivers/net/s2io.c | 22 +++++++++++-----------
drivers/net/s2io.h | 17 +++++++----------
2 files changed, 18 insertions(+), 21 deletions(-)
--- linux-2.6.15-mm1-full/drivers/net/s2io.h.old 2006-01-05 20:46:34.000000000 +0100
+++ linux-2.6.15-mm1-full/drivers/net/s2io.h 2006-01-05 21:10:33.000000000 +0100
@@ -64,7 +64,7 @@
#define INTR_DBG 4
/* Global variable that defines the present debug level of the driver. */
-int debug_level = ERR_DBG; /* Default level. */
+static int debug_level = ERR_DBG;
/* DEBUG message print. */
#define DBG_PRINT(dbg_level, args...) if(!(debug_level<dbg_level)) printk(args)
@@ -268,7 +268,7 @@
#define MAX_RX_RINGS 8
/* FIFO mappings for all possible number of fifos configured */
-int fifo_map[][MAX_TX_FIFOS] = {
+static int fifo_map[][MAX_TX_FIFOS] = {
{0, 0, 0, 0, 0, 0, 0, 0},
{0, 0, 0, 0, 1, 1, 1, 1},
{0, 0, 0, 1, 1, 1, 2, 2},
@@ -911,18 +911,16 @@
static void alarm_intr_handler(struct s2io_nic *sp);
static int s2io_starter(void);
-void s2io_closer(void);
static void s2io_tx_watchdog(struct net_device *dev);
static void s2io_tasklet(unsigned long dev_addr);
static void s2io_set_multicast(struct net_device *dev);
static int rx_osm_handler(ring_info_t *ring_data, RxD_t * rxdp);
-void s2io_link(nic_t * sp, int link);
-void s2io_reset(nic_t * sp);
+static void s2io_link(nic_t * sp, int link);
#if defined(CONFIG_S2IO_NAPI)
static int s2io_poll(struct net_device *dev, int *budget);
#endif
static void s2io_init_pci(nic_t * sp);
-int s2io_set_mac_addr(struct net_device *dev, u8 * addr);
+static int s2io_set_mac_addr(struct net_device *dev, u8 * addr);
static void s2io_alarm_handle(unsigned long data);
static int s2io_enable_msi(nic_t *nic);
static irqreturn_t s2io_msi_handle(int irq, void *dev_id, struct pt_regs *regs);
@@ -930,14 +928,13 @@
s2io_msix_ring_handle(int irq, void *dev_id, struct pt_regs *regs);
static irqreturn_t
s2io_msix_fifo_handle(int irq, void *dev_id, struct pt_regs *regs);
-int s2io_enable_msi_x(nic_t *nic);
static irqreturn_t s2io_isr(int irq, void *dev_id, struct pt_regs *regs);
static int verify_xena_quiescence(nic_t *sp, u64 val64, int flag);
static struct ethtool_ops netdev_ethtool_ops;
static void s2io_set_link(unsigned long data);
-int s2io_set_swapper(nic_t * sp);
+static int s2io_set_swapper(nic_t * sp);
static void s2io_card_down(nic_t *nic);
static int s2io_card_up(nic_t *nic);
-int get_xena_rev_id(struct pci_dev *pdev);
-void restore_xmsi_data(nic_t *nic);
+static int get_xena_rev_id(struct pci_dev *pdev);
+static void restore_xmsi_data(nic_t *nic);
#endif /* _S2IO_H */
--- linux-2.6.15-mm1-full/drivers/net/s2io.c.old 2006-01-05 20:45:51.000000000 +0100
+++ linux-2.6.15-mm1-full/drivers/net/s2io.c 2006-01-05 20:54:26.000000000 +0100
@@ -72,8 +72,8 @@
static char s2io_driver_name[] = "Neterion";
static char s2io_driver_version[] = DRV_VERSION;
-int rxd_size[4] = {32,48,48,64};
-int rxd_count[4] = {127,85,85,63};
+static int rxd_size[4] = {32,48,48,64};
+static int rxd_count[4] = {127,85,85,63};
static inline int RXD_IS_UP2DT(RxD_t *rxdp)
{
@@ -2127,7 +2127,7 @@
}
}
-int fill_rxd_3buf(nic_t *nic, RxD_t *rxdp, struct sk_buff *skb)
+static int fill_rxd_3buf(nic_t *nic, RxD_t *rxdp, struct sk_buff *skb)
{
struct net_device *dev = nic->dev;
struct sk_buff *frag_list;
@@ -2852,7 +2852,7 @@
* void.
*/
-void s2io_reset(nic_t * sp)
+static void s2io_reset(nic_t * sp)
{
XENA_dev_config_t __iomem *bar0 = sp->bar0;
u64 val64;
@@ -2940,7 +2940,7 @@
* SUCCESS on success and FAILURE on failure.
*/
-int s2io_set_swapper(nic_t * sp)
+static int s2io_set_swapper(nic_t * sp)
{
struct net_device *dev = sp->dev;
XENA_dev_config_t __iomem *bar0 = sp->bar0;
@@ -3089,7 +3089,7 @@
return ret;
}
-void restore_xmsi_data(nic_t *nic)
+static void restore_xmsi_data(nic_t *nic)
{
XENA_dev_config_t __iomem *bar0 = nic->bar0;
u64 val64;
@@ -3180,7 +3180,7 @@
return 0;
}
-int s2io_enable_msi_x(nic_t *nic)
+static int s2io_enable_msi_x(nic_t *nic)
{
XENA_dev_config_t __iomem *bar0 = nic->bar0;
u64 tx_mat, rx_mat;
@@ -4128,7 +4128,7 @@
* as defined in errno.h file on failure.
*/
-int s2io_set_mac_addr(struct net_device *dev, u8 * addr)
+static int s2io_set_mac_addr(struct net_device *dev, u8 * addr)
{
nic_t *sp = dev->priv;
XENA_dev_config_t __iomem *bar0 = sp->bar0;
@@ -5713,7 +5713,7 @@
* void.
*/
-void s2io_link(nic_t * sp, int link)
+static void s2io_link(nic_t * sp, int link)
{
struct net_device *dev = (struct net_device *) sp->dev;
@@ -5738,7 +5738,7 @@
* returns the revision ID of the device.
*/
-int get_xena_rev_id(struct pci_dev *pdev)
+static int get_xena_rev_id(struct pci_dev *pdev)
{
u8 id = 0;
int ret;
@@ -6343,7 +6343,7 @@
* Description: This function is the cleanup routine for the driver. It unregist * ers the driver.
*/
-void s2io_closer(void)
+static void s2io_closer(void)
{
pci_unregister_driver(&s2io_driver);
DBG_PRINT(INIT_DBG, "cleanup done\n");
^ permalink raw reply
* [2.6 patch] drivers/net/arcnet/: possible cleanups
From: Adrian Bunk @ 2006-01-14 2:10 UTC (permalink / raw)
To: Jeff Garzik, akpm, linux-kernel, netdev
This patch contains the following possible cleanups:
- make needlessly global code static
- arcnet.c: remove the unneeded EXPORT_SYMBOL(arc_proto_null)
- arcnet.c: remove the unneeded EXPORT_SYMBOL(arcnet_dump_packet)
To make Jeff happy, arcnet.c still prints
arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/arcnet/arc-rawmode.c | 2 +-
drivers/net/arcnet/arcnet.c | 15 +++++++++------
drivers/net/arcnet/rfc1051.c | 2 +-
drivers/net/arcnet/rfc1201.c | 2 +-
include/linux/arcdevice.h | 10 ----------
5 files changed, 12 insertions(+), 19 deletions(-)
diff -puN drivers/net/arcnet/arcnet.c~drivers-net-arcnet-possible-cleanups drivers/net/arcnet/arcnet.c
--- devel/drivers/net/arcnet/arcnet.c~drivers-net-arcnet-possible-cleanups 2005-07-09 01:24:43.000000000 -0700
+++ devel-akpm/drivers/net/arcnet/arcnet.c 2005-07-09 01:24:43.000000000 -0700
@@ -61,6 +59,7 @@ static int null_build_header(struct sk_b
static int null_prepare_tx(struct net_device *dev, struct archdr *pkt,
int length, int bufnum);
+static void arcnet_rx(struct net_device *dev, int bufnum);
/*
* one ArcProto per possible proto ID. None of the elements of
@@ -71,7 +70,7 @@ static int null_prepare_tx(struct net_de
struct ArcProto *arc_proto_map[256], *arc_proto_default,
*arc_bcast_proto, *arc_raw_proto;
-struct ArcProto arc_proto_null =
+static struct ArcProto arc_proto_null =
{
.suffix = '?',
.mtu = XMTU,
@@ -90,7 +89,6 @@ EXPORT_SYMBOL(arc_proto_map);
EXPORT_SYMBOL(arc_proto_default);
EXPORT_SYMBOL(arc_bcast_proto);
EXPORT_SYMBOL(arc_raw_proto);
-EXPORT_SYMBOL(arc_proto_null);
EXPORT_SYMBOL(arcnet_unregister_proto);
EXPORT_SYMBOL(arcnet_debug);
EXPORT_SYMBOL(alloc_arcdev);
@@ -118,7 +116,7 @@ static int __init arcnet_init(void)
arcnet_debug = debug;
- printk(VERSION);
+ printk("arcnet loaded.\n");
#ifdef ALPHA_WARNING
BUGLVL(D_EXTRA) {
@@ -178,8 +176,8 @@ EXPORT_SYMBOL(arcnet_dump_skb);
* Dump the contents of an ARCnet buffer
*/
#if (ARCNET_DEBUG_MAX & (D_RX | D_TX))
-void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc,
- int take_arcnet_lock)
+static void arcnet_dump_packet(struct net_device *dev, int bufnum,
+ char *desc, int take_arcnet_lock)
{
struct arcnet_local *lp = dev->priv;
int i, length;
@@ -208,7 +206,10 @@ void arcnet_dump_packet(struct net_devic
}
-EXPORT_SYMBOL(arcnet_dump_packet);
+#else
+
+#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) do { } while (0)
+
#endif
@@ -987,7 +988,7 @@ irqreturn_t arcnet_interrupt(int irq, vo
* This is a generic packet receiver that calls arcnet??_rx depending on the
* protocol ID found.
*/
-void arcnet_rx(struct net_device *dev, int bufnum)
+static void arcnet_rx(struct net_device *dev, int bufnum)
{
struct arcnet_local *lp = dev->priv;
struct archdr pkt;
diff -puN drivers/net/arcnet/arc-rawmode.c~drivers-net-arcnet-possible-cleanups drivers/net/arcnet/arc-rawmode.c
--- devel/drivers/net/arcnet/arc-rawmode.c~drivers-net-arcnet-possible-cleanups 2005-07-09 01:24:43.000000000 -0700
+++ devel-akpm/drivers/net/arcnet/arc-rawmode.c 2005-07-09 01:24:43.000000000 -0700
@@ -42,7 +42,7 @@ static int build_header(struct sk_buff *
static int prepare_tx(struct net_device *dev, struct archdr *pkt, int length,
int bufnum);
-struct ArcProto rawmode_proto =
+static struct ArcProto rawmode_proto =
{
.suffix = 'r',
.mtu = XMTU,
diff -puN drivers/net/arcnet/rfc1051.c~drivers-net-arcnet-possible-cleanups drivers/net/arcnet/rfc1051.c
--- devel/drivers/net/arcnet/rfc1051.c~drivers-net-arcnet-possible-cleanups 2005-07-09 01:24:43.000000000 -0700
+++ devel-akpm/drivers/net/arcnet/rfc1051.c 2005-07-09 01:24:43.000000000 -0700
@@ -43,7 +43,7 @@ static int prepare_tx(struct net_device
int bufnum);
-struct ArcProto rfc1051_proto =
+static struct ArcProto rfc1051_proto =
{
.suffix = 's',
.mtu = XMTU - RFC1051_HDR_SIZE,
diff -puN drivers/net/arcnet/rfc1201.c~drivers-net-arcnet-possible-cleanups drivers/net/arcnet/rfc1201.c
--- devel/drivers/net/arcnet/rfc1201.c~drivers-net-arcnet-possible-cleanups 2005-07-09 01:24:43.000000000 -0700
+++ devel-akpm/drivers/net/arcnet/rfc1201.c 2005-07-09 01:24:43.000000000 -0700
@@ -43,7 +43,7 @@ static int prepare_tx(struct net_device
int bufnum);
static int continue_tx(struct net_device *dev, int bufnum);
-struct ArcProto rfc1201_proto =
+static struct ArcProto rfc1201_proto =
{
.suffix = 'a',
.mtu = 1500, /* could be more, but some receivers can't handle it... */
diff -puN include/linux/arcdevice.h~drivers-net-arcnet-possible-cleanups include/linux/arcdevice.h
--- devel/include/linux/arcdevice.h~drivers-net-arcnet-possible-cleanups 2005-07-09 01:24:43.000000000 -0700
+++ devel-akpm/include/linux/arcdevice.h 2005-07-09 01:24:43.000000000 -0700
@@ -206,7 +206,6 @@ struct ArcProto {
extern struct ArcProto *arc_proto_map[256], *arc_proto_default,
*arc_bcast_proto, *arc_raw_proto;
-extern struct ArcProto arc_proto_null;
/*
@@ -334,17 +333,9 @@ void arcnet_dump_skb(struct net_device *
#define arcnet_dump_skb(dev,skb,desc) ;
#endif
-#if (ARCNET_DEBUG_MAX & D_RX) || (ARCNET_DEBUG_MAX & D_TX)
-void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc,
- int take_arcnet_lock);
-#else
-#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) ;
-#endif
-
void arcnet_unregister_proto(struct ArcProto *proto);
irqreturn_t arcnet_interrupt(int irq, void *dev_id, struct pt_regs *regs);
struct net_device *alloc_arcdev(char *name);
-void arcnet_rx(struct net_device *dev, int bufnum);
#endif /* __KERNEL__ */
#endif /* _LINUX_ARCDEVICE_H */
_
^ permalink raw reply
* [2.6 patch] move some code to net/ipx/af_ipx.c
From: Adrian Bunk @ 2006-01-14 2:10 UTC (permalink / raw)
To: acme; +Cc: linux-kernel, netdev
This patch moves some code only used in this file to net/ipx/af_ipx.c .
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This version was slightly adapted to apply against Linus' current tree.
include/net/p8022.h | 13 -----
net/802/Makefile | 14 ++---
net/802/p8022.c | 66 ---------------------------
net/802/p8023.c | 61 -------------------------
net/8021q/vlan.c | 1
net/8021q/vlan_dev.c | 1
net/ethernet/Makefile | 2
net/ethernet/pe2.c | 39 ----------------
net/ipx/af_ipx.c | 102 ++++++++++++++++++++++++++++++++++++++++--
9 files changed, 106 insertions(+), 193 deletions(-)
--- linux-2.6.15-rc1-mm1-full/net/ethernet/Makefile.old 2005-11-18 02:15:17.000000000 +0100
+++ linux-2.6.15-rc1-mm1-full/net/ethernet/Makefile 2005-11-18 02:15:22.000000000 +0100
@@ -4,5 +4,3 @@
obj-y += eth.o
obj-$(CONFIG_SYSCTL) += sysctl_net_ether.o
-obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
-obj-$(subst m,y,$(CONFIG_ATALK)) += pe2.o
--- linux-2.6.15-rc1-mm1-full/net/8021q/vlan.c.old 2005-11-18 02:19:40.000000000 +0100
+++ linux-2.6.15-rc1-mm1-full/net/8021q/vlan.c 2005-11-18 02:19:46.000000000 +0100
@@ -26,7 +26,6 @@
#include <linux/mm.h>
#include <linux/in.h>
#include <linux/init.h>
-#include <net/p8022.h>
#include <net/arp.h>
#include <linux/rtnetlink.h>
#include <linux/notifier.h>
--- linux-2.6.15-rc1-mm1-full/net/8021q/vlan_dev.c.old 2005-11-18 02:19:55.000000000 +0100
+++ linux-2.6.15-rc1-mm1-full/net/8021q/vlan_dev.c 2005-11-18 02:19:58.000000000 +0100
@@ -29,7 +29,6 @@
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
#include <net/datalink.h>
-#include <net/p8022.h>
#include <net/arp.h>
#include "vlan.h"
--- linux-2.6.15-rc1-mm1-full/net/ipx/af_ipx.c.old 2005-11-18 02:17:00.000000000 +0100
+++ linux-2.6.15-rc1-mm1-full/net/ipx/af_ipx.c 2005-11-18 02:26:01.000000000 +0100
@@ -48,10 +48,10 @@
#include <linux/termios.h>
#include <net/ipx.h>
-#include <net/p8022.h>
#include <net/psnap.h>
#include <net/sock.h>
#include <net/tcp_states.h>
+#include <net/llc.h>
#include <asm/uaccess.h>
@@ -1939,8 +1939,104 @@
.notifier_call = ipxitf_device_event,
};
-extern struct datalink_proto *make_EII_client(void);
-extern void destroy_EII_client(struct datalink_proto *);
+static int p8022_request(struct datalink_proto *dl, struct sk_buff *skb,
+ unsigned char *dest)
+{
+ llc_build_and_send_ui_pkt(dl->sap, skb, dest, dl->sap->laddr.lsap);
+ return 0;
+}
+
+static struct datalink_proto *register_8022_client(unsigned char type,
+ int (*func)(struct sk_buff *skb,
+ struct net_device *dev,
+ struct packet_type *pt,
+ struct net_device *orig_dev))
+{
+ struct datalink_proto *proto;
+
+ proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
+ if (proto) {
+ proto->type[0] = type;
+ proto->header_length = 3;
+ proto->request = p8022_request;
+ proto->sap = llc_sap_open(type, func);
+ if (!proto->sap) {
+ kfree(proto);
+ proto = NULL;
+ }
+ }
+ return proto;
+}
+
+static void unregister_8022_client(struct datalink_proto *proto)
+{
+ llc_sap_put(proto->sap);
+ kfree(proto);
+}
+
+/*
+ * Place an 802.3 header on a packet. The driver will do the mac
+ * addresses, we just need to give it the buffer length.
+ */
+static int p8023_request(struct datalink_proto *dl,
+ struct sk_buff *skb, unsigned char *dest_node)
+{
+ struct net_device *dev = skb->dev;
+
+ dev->hard_header(skb, dev, ETH_P_802_3, dest_node, NULL, skb->len);
+ return dev_queue_xmit(skb);
+}
+
+/*
+ * Create an 802.3 client. Note there can be only one 802.3 client
+ */
+static struct datalink_proto *make_8023_client(void)
+{
+ struct datalink_proto *proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
+
+ if (proto) {
+ proto->header_length = 0;
+ proto->request = p8023_request;
+ }
+ return proto;
+}
+
+/*
+ * Destroy the 802.3 client.
+ */
+static void destroy_8023_client(struct datalink_proto *dl)
+{
+ kfree(dl);
+}
+
+static int pEII_request(struct datalink_proto *dl,
+ struct sk_buff *skb, unsigned char *dest_node)
+{
+ struct net_device *dev = skb->dev;
+
+ skb->protocol = htons(ETH_P_IPX);
+ if (dev->hard_header)
+ dev->hard_header(skb, dev, ETH_P_IPX,
+ dest_node, NULL, skb->len);
+ return dev_queue_xmit(skb);
+}
+
+static struct datalink_proto *make_EII_client(void)
+{
+ struct datalink_proto *proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
+
+ if (proto) {
+ proto->header_length = 0;
+ proto->request = pEII_request;
+ }
+
+ return proto;
+}
+
+static void destroy_EII_client(struct datalink_proto *dl)
+{
+ kfree(dl);
+}
static unsigned char ipx_8022_type = 0xE0;
static unsigned char ipx_snap_id[5] = { 0x0, 0x0, 0x0, 0x81, 0x37 };
--- linux-2.6.15-rc1-mm1-full/include/net/p8022.h 2005-10-28 02:02:08.000000000 +0200
+++ /dev/null 2005-11-08 19:07:57.000000000 +0100
@@ -1,13 +0,0 @@
-#ifndef _NET_P8022_H
-#define _NET_P8022_H
-extern struct datalink_proto *
- register_8022_client(unsigned char type,
- int (*func)(struct sk_buff *skb,
- struct net_device *dev,
- struct packet_type *pt,
- struct net_device *orig_dev));
-extern void unregister_8022_client(struct datalink_proto *proto);
-
-extern struct datalink_proto *make_8023_client(void);
-extern void destroy_8023_client(struct datalink_proto *dl);
-#endif
--- linux-2.6.15-rc1-mm1-full/net/ethernet/pe2.c 2005-11-17 21:30:56.000000000 +0100
+++ /dev/null 2005-11-08 19:07:57.000000000 +0100
@@ -1,39 +0,0 @@
-#include <linux/in.h>
-#include <linux/mm.h>
-#include <linux/module.h>
-#include <linux/netdevice.h>
-#include <linux/skbuff.h>
-
-#include <net/datalink.h>
-
-static int pEII_request(struct datalink_proto *dl,
- struct sk_buff *skb, unsigned char *dest_node)
-{
- struct net_device *dev = skb->dev;
-
- skb->protocol = htons(ETH_P_IPX);
- if (dev->hard_header)
- dev->hard_header(skb, dev, ETH_P_IPX,
- dest_node, NULL, skb->len);
- return dev_queue_xmit(skb);
-}
-
-struct datalink_proto *make_EII_client(void)
-{
- struct datalink_proto *proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
-
- if (proto) {
- proto->header_length = 0;
- proto->request = pEII_request;
- }
-
- return proto;
-}
-
-void destroy_EII_client(struct datalink_proto *dl)
-{
- kfree(dl);
-}
-
-EXPORT_SYMBOL(destroy_EII_client);
-EXPORT_SYMBOL(make_EII_client);
--- linux-2.6.15-rc1-mm1-full/net/802/p8022.c 2005-10-28 02:02:08.000000000 +0200
+++ /dev/null 2005-11-08 19:07:57.000000000 +0100
@@ -1,66 +0,0 @@
-/*
- * NET3: Support for 802.2 demultiplexing off Ethernet (Token ring
- * is kept separate see p8022tr.c)
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- *
- * Demultiplex 802.2 encoded protocols. We match the entry by the
- * SSAP/DSAP pair and then deliver to the registered datalink that
- * matches. The control byte is ignored and handling of such items
- * is up to the routine passed the frame.
- *
- * Unlike the 802.3 datalink we have a list of 802.2 entries as
- * there are multiple protocols to demux. The list is currently
- * short (3 or 4 entries at most). The current demux assumes this.
- */
-#include <linux/module.h>
-#include <linux/netdevice.h>
-#include <linux/skbuff.h>
-#include <net/datalink.h>
-#include <linux/mm.h>
-#include <linux/in.h>
-#include <linux/init.h>
-#include <net/llc.h>
-#include <net/p8022.h>
-
-static int p8022_request(struct datalink_proto *dl, struct sk_buff *skb,
- unsigned char *dest)
-{
- llc_build_and_send_ui_pkt(dl->sap, skb, dest, dl->sap->laddr.lsap);
- return 0;
-}
-
-struct datalink_proto *register_8022_client(unsigned char type,
- int (*func)(struct sk_buff *skb,
- struct net_device *dev,
- struct packet_type *pt,
- struct net_device *orig_dev))
-{
- struct datalink_proto *proto;
-
- proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
- if (proto) {
- proto->type[0] = type;
- proto->header_length = 3;
- proto->request = p8022_request;
- proto->sap = llc_sap_open(type, func);
- if (!proto->sap) {
- kfree(proto);
- proto = NULL;
- }
- }
- return proto;
-}
-
-void unregister_8022_client(struct datalink_proto *proto)
-{
- llc_sap_put(proto->sap);
- kfree(proto);
-}
-
-EXPORT_SYMBOL(register_8022_client);
-EXPORT_SYMBOL(unregister_8022_client);
-
-MODULE_LICENSE("GPL");
--- linux-2.6.15-rc1-mm1-full/net/802/p8023.c 2005-11-17 21:30:55.000000000 +0100
+++ /dev/null 2005-11-08 19:07:57.000000000 +0100
@@ -1,61 +0,0 @@
-/*
- * NET3: 802.3 data link hooks used for IPX 802.3
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- *
- * 802.3 isn't really a protocol data link layer. Some old IPX stuff
- * uses it however. Note that there is only one 802.3 protocol layer
- * in the system. We don't currently support different protocols
- * running raw 802.3 on different devices. Thankfully nobody else
- * has done anything like the old IPX.
- */
-
-#include <linux/in.h>
-#include <linux/mm.h>
-#include <linux/module.h>
-#include <linux/netdevice.h>
-#include <linux/skbuff.h>
-
-#include <net/datalink.h>
-#include <net/p8022.h>
-
-/*
- * Place an 802.3 header on a packet. The driver will do the mac
- * addresses, we just need to give it the buffer length.
- */
-static int p8023_request(struct datalink_proto *dl,
- struct sk_buff *skb, unsigned char *dest_node)
-{
- struct net_device *dev = skb->dev;
-
- dev->hard_header(skb, dev, ETH_P_802_3, dest_node, NULL, skb->len);
- return dev_queue_xmit(skb);
-}
-
-/*
- * Create an 802.3 client. Note there can be only one 802.3 client
- */
-struct datalink_proto *make_8023_client(void)
-{
- struct datalink_proto *proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
-
- if (proto) {
- proto->header_length = 0;
- proto->request = p8023_request;
- }
- return proto;
-}
-
-/*
- * Destroy the 802.3 client.
- */
-void destroy_8023_client(struct datalink_proto *dl)
-{
- kfree(dl);
-}
-
-EXPORT_SYMBOL(destroy_8023_client);
-EXPORT_SYMBOL(make_8023_client);
--- linux-2.6.15-mm3-full/net/802/Makefile.old 2006-01-14 02:55:28.000000000 +0100
+++ linux-2.6.15-mm3-full/net/802/Makefile 2006-01-14 02:55:50.000000000 +0100
@@ -4,10 +4,10 @@
# Check the p8022 selections against net/core/Makefile.
obj-$(CONFIG_SYSCTL) += sysctl_net_802.o
-obj-$(CONFIG_LLC) += p8022.o psnap.o
-obj-$(CONFIG_TR) += p8022.o psnap.o tr.o sysctl_net_802.o
-obj-$(CONFIG_NET_FC) += fc.o
-obj-$(CONFIG_FDDI) += fddi.o
-obj-$(CONFIG_HIPPI) += hippi.o
-obj-$(CONFIG_IPX) += p8022.o psnap.o p8023.o
-obj-$(CONFIG_ATALK) += p8022.o psnap.o
+obj-$(CONFIG_LLC) += psnap.o
+obj-$(CONFIG_TR) += psnap.o tr.o sysctl_net_802.o
+obj-$(CONFIG_NET_FC) += fc.o
+obj-$(CONFIG_FDDI) += fddi.o
+obj-$(CONFIG_HIPPI) += hippi.o
+obj-$(CONFIG_IPX) += psnap.o
+obj-$(CONFIG_ATALK) += psnap.o
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Adrian Bunk @ 2006-01-14 2:29 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Jens Axboe, Andrew Morton, Linus Torvalds, jgarzik, netdev,
linux-kernel, Roman Zippel
In-Reply-To: <20060113192813.GA10560@mars.ravnborg.org>
On Fri, Jan 13, 2006 at 08:28:13PM +0100, Sam Ravnborg wrote:
> On Fri, Jan 13, 2006 at 08:23:16PM +0100, Jens Axboe wrote:
> >
> > 'select' is really cool as a concept, but when you can't figure out why
> > you cannot disable CONFIG_FOO because CONFIG_BAR selects it it's really
> > annoying. Would be nice to actually be able to see if another option has
> > selected this option.
>
> In menuconfig:
>
> Typing '?' on CONFIG_HOTPLUG revealed:
> Selected by: PCCARD || HOTPLUG_PCI && PCI && EXPERIMENTAL || FW_LOADER
>...
Is there any trick to see them all when they are longer than the line in
the terminal (e.g. what selects FW_LOADER?)?
> Sam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Randy.Dunlap @ 2006-01-14 5:05 UTC (permalink / raw)
To: Adrian Bunk
Cc: sam, axboe, akpm, torvalds, jgarzik, netdev, linux-kernel, zippel
In-Reply-To: <20060114022949.GI29663@stusta.de>
On Sat, 14 Jan 2006 03:29:49 +0100 Adrian Bunk wrote:
> On Fri, Jan 13, 2006 at 08:28:13PM +0100, Sam Ravnborg wrote:
> > On Fri, Jan 13, 2006 at 08:23:16PM +0100, Jens Axboe wrote:
> > >
> > > 'select' is really cool as a concept, but when you can't figure out why
> > > you cannot disable CONFIG_FOO because CONFIG_BAR selects it it's really
> > > annoying. Would be nice to actually be able to see if another option has
> > > selected this option.
> >
> > In menuconfig:
> >
> > Typing '?' on CONFIG_HOTPLUG revealed:
> > Selected by: PCCARD || HOTPLUG_PCI && PCI && EXPERIMENTAL || FW_LOADER
> >...
>
> Is there any trick to see them all when they are longer than the line in
> the terminal (e.g. what selects FW_LOADER?)?
Use the right/left arrow keys to scroll horizontally.
---
~Randy
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Johannes Berg @ 2006-01-14 9:28 UTC (permalink / raw)
To: Stuffed Crust; +Cc: netdev, linux-kernel
In-Reply-To: <20060114011726.GA19950@shaftnet.org>
[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]
On Fri, 2006-01-13 at 20:17 -0500, Stuffed Crust wrote:
> If you're talking about the former.. things get quite complicated, but
> that could be handled by having two WiPHY devices registered.
The former; and yes, I thought about that too -- having a driver that
shows two physical WiPHY devices as a single logical WiPHY device and
distributes virtual devices among them...
> As for the latter, when you factor in the needs of 802.11d and its
> dependents (802.11j, 802.11k, and others) the stack is going to need to
> be aware of the available channel sets; both in the sense of hardware
> support and also the various regulatory requirements.
>
> The hardware knows what frequencies it supports. Unfortunately this has
> to be a somewhat dynamic thing, as this is often not queryable until the
> device firmware is up and running.
>
> This can be accomplished by passing a static table to the
> register_wiphy_device() call (or perhaps via a struct wiphy_dev
> parameter) or through a more explicit, dynamic interface like:
>
> wiphy_register_supported_frequency(hw, 2412).
Yeah, this is about what I thought of -- and it makes me wonder if the
stack really should be aware of the channelization, or if the WiPHY
driver might better just handle it itself.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox