* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-10 17:21 ` Jean Tourrilhes
@ 2004-03-10 17:29 ` Christoph Hellwig
2004-03-10 17:29 ` Jeff Garzik
` (2 subsequent siblings)
3 siblings, 0 replies; 33+ messages in thread
From: Christoph Hellwig @ 2004-03-10 17:29 UTC (permalink / raw)
To: jt
Cc: Christoph Hellwig, prism54-devel, David S. Miller, Jeff Garzik,
netdev, Linux kernel mailing list
On Wed, Mar 10, 2004 at 09:21:14AM -0800, Jean Tourrilhes wrote:
> > --- linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c Thu Jan 1 00:00:00 1970
> > +++ linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c Thu Mar 4 02:00:01 2004
> >
> > WDS doesn't belong into a driver but in higher-level code.
>
> The big 802.11 reorg can only happen when HostAP is in the
> kernel.
I don't quite understand that comment. This feature doesn't belong into
a driver. Whether it's some day implemented in a hypothetic 802.11 midlayer
that can only be done with another driver merged is a different question,
isn't it?
>
> Regards,
>
> Jean
>
---end quoted text---
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-10 17:21 ` Jean Tourrilhes
2004-03-10 17:29 ` Christoph Hellwig
@ 2004-03-10 17:29 ` Jeff Garzik
2004-03-10 17:52 ` Jean Tourrilhes
2004-03-10 18:07 ` [PATCH 2.6] Intersil Prism54 wireless driver Jeff Garzik
2004-03-10 22:17 ` Luis R. Rodriguez
3 siblings, 1 reply; 33+ messages in thread
From: Jeff Garzik @ 2004-03-10 17:29 UTC (permalink / raw)
To: jt
Cc: Christoph Hellwig, prism54-devel, David S. Miller, netdev,
Linux kernel mailing list
Jean Tourrilhes wrote:
> On Wed, Mar 10, 2004 at 04:55:48PM +0000, Christoph Hellwig wrote:
>>+MODULE_PARM(init_mode, "i");
>>+MODULE_PARM_DESC(init_mode,
>>+ "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client (Default)\n3: Master / Access Point\n4: Repeater (Not supported yet)\n5: Secondary (Not supported yet)\n6: Monitor");
>>
>> Please use module_param
>
>
> I would even say that this is useless because the driver
> support WE, and WE scripts set the mode before the card is up.
module_param() is a type-safe interface roughly identical to
MODULE_PARM(). Therefore, if MODULE_PARM() works, module_param() works
also.
>>diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c
>>--- linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c Thu Jan 1 00:00:00 1970
>>+++ linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c Thu Mar 4 02:00:01 2004
>>
>> WDS doesn't belong into a driver but in higher-level code.
>
>
> The big 802.11 reorg can only happen when HostAP is in the
> kernel.
ISTR it needed some cleaning up before it could go in.
Further, in Linux, there is _never_ a requirement that "this driver be
included before we can clean up." You can start the re-org any time you
wish. Out-of-tree maintainers can follow the re-org, sometimes more easily.
Jeff
P.S. I still need to look at your netlink thing. Seems like a decent
direction.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-10 17:29 ` Jeff Garzik
@ 2004-03-10 17:52 ` Jean Tourrilhes
2004-03-10 17:58 ` Jeff Garzik
0 siblings, 1 reply; 33+ messages in thread
From: Jean Tourrilhes @ 2004-03-10 17:52 UTC (permalink / raw)
To: Jeff Garzik
Cc: Christoph Hellwig, David S. Miller, netdev,
Linux kernel mailing list
On Wed, Mar 10, 2004 at 12:29:59PM -0500, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >On Wed, Mar 10, 2004 at 04:55:48PM +0000, Christoph Hellwig wrote:
> >>+MODULE_PARM(init_mode, "i");
> >>+MODULE_PARM_DESC(init_mode,
> >>+ "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client
> >>(Default)\n3: Master / Access Point\n4: Repeater (Not supported yet)\n5:
> >>Secondary (Not supported yet)\n6: Monitor");
> >>
> >> Please use module_param
> >
> >
> > I would even say that this is useless because the driver
> >support WE, and WE scripts set the mode before the card is up.
>
> module_param() is a type-safe interface roughly identical to
> MODULE_PARM(). Therefore, if MODULE_PARM() works, module_param() works
> also.
Yes, I know, I've been doing that for IrDA. What I meant was
that this specific module parameter could be remove entirely because
redundant.
> >>diff -Naur -X /home/mcgrof/lib/dontdiff
> >>linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c
> >>linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c
> >>--- linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c Thu Jan 1
> >>00:00:00 1970
> >>+++ linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c Thu
> >>Mar 4 02:00:01 2004
> >>
> >> WDS doesn't belong into a driver but in higher-level code.
> >
> >
> > The big 802.11 reorg can only happen when HostAP is in the
> >kernel.
>
> ISTR it needed some cleaning up before it could go in.
I think it would be nice to give some more explicit feedback
to Jouni.
> Further, in Linux, there is _never_ a requirement that "this driver be
> included before we can clean up." You can start the re-org any time you
> wish. Out-of-tree maintainers can follow the re-org, sometimes more easily.
You misunderstood. The HostAP driver has a pretty much
complete generic 802.11 stack. However, other driver can't depend on
that code until it's in the kernel.
By "big 802.11 reorg", I meant "make the other driver depend
on HostAP 802.11 code".
Of course, I'm quite partial to the HostAP code because I'm
more familiar with it and I believe it's the most advanced (host WEP,
802.1x, WPA, AP...). Other candidated are linux-wlan-ng or the *BSD
stack (by the way of the MadWifi driver).
> Jeff
>
>
>
> P.S. I still need to look at your netlink thing. Seems like a decent
> direction.
Thanks ;-) I would need to make sure that there is no popular
driver still using the old driver API (orinoco_cs is converted in the
CVS).
Jean
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-10 17:52 ` Jean Tourrilhes
@ 2004-03-10 17:58 ` Jeff Garzik
2004-03-10 23:37 ` James Ketrenos
2004-03-11 2:48 ` Jouni Malinen
0 siblings, 2 replies; 33+ messages in thread
From: Jeff Garzik @ 2004-03-10 17:58 UTC (permalink / raw)
To: jt; +Cc: Christoph Hellwig, David S. Miller, netdev,
Linux kernel mailing list
Jean Tourrilhes wrote:
> You misunderstood. The HostAP driver has a pretty much
> complete generic 802.11 stack. However, other driver can't depend on
> that code until it's in the kernel.
> By "big 802.11 reorg", I meant "make the other driver depend
> on HostAP 802.11 code".
> Of course, I'm quite partial to the HostAP code because I'm
> more familiar with it and I believe it's the most advanced (host WEP,
> 802.1x, WPA, AP...). Other candidated are linux-wlan-ng or the *BSD
> stack (by the way of the MadWifi driver).
Ah! I did indeed misunderstand.
Yes, it would be good to end the cycle of re-implementing 802.11 over
and over again ;-)
So here is my suggested plan:
* I merge prism54 upstream
* I create wireless-2.6 queue
* somebody (you, Jouni(sp?)) submits HostAP to me
* I merge HostAP
* submit rtnetlink patches to me
* start working on generic 802.11 stack in wireless-2.6 queue
* at the same time, migrate away from iw_handler to "wireless_ops" (i.e.
something like ethtool_ops)
* once things have stabilized again, merge upstream
I'm not sure about the order of the last few steps, you know better than
I what dependencies exist.
Jeff
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-10 17:58 ` Jeff Garzik
@ 2004-03-10 23:37 ` James Ketrenos
2004-03-11 2:31 ` Jouni Malinen
2004-03-11 2:48 ` Jouni Malinen
1 sibling, 1 reply; 33+ messages in thread
From: James Ketrenos @ 2004-03-10 23:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: jt, Christoph Hellwig, David S. Miller, netdev,
Linux kernel mailing list
Jeff Garzik wrote:
> Yes, it would be good to end the cycle of re-implementing 802.11 over
> and over again ;-)
< snip >
> * start working on generic 802.11 stack in wireless-2.6 queue
As we're currently walking the path of implementing the same thing for the
IPW2100 driver, being able to re-use this code would be _very nice_.
I'd like to get WEP into IPW2100 as soon as possible, and would like to do so in
a way that would make transitioning to a common 802.11 layer seamless (or at
least reasonably isolated). Any suggestions on how to best do this, or where we
might be able to help, would be much appreciated.
I'm very interested in these discussions, so if they move to or are being
discussed on another list (besides netdev), please let me know where.
Thanks,
James
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-10 23:37 ` James Ketrenos
@ 2004-03-11 2:31 ` Jouni Malinen
2004-03-11 2:43 ` Jeff Garzik
0 siblings, 1 reply; 33+ messages in thread
From: Jouni Malinen @ 2004-03-11 2:31 UTC (permalink / raw)
To: James Ketrenos
Cc: Jeff Garzik, jt, Christoph Hellwig, David S. Miller, netdev,
Linux kernel mailing list
On Wed, Mar 10, 2004 at 05:37:16PM -0600, James Ketrenos wrote:
> I'd like to get WEP into IPW2100 as soon as possible, and would like to do
> so in a way that would make transitioning to a common 802.11 layer seamless
> (or at least reasonably isolated). Any suggestions on how to best do this,
> or where we might be able to help, would be much appreciated.
Host AP driver (http://hostap.epitest.fi/) has generic (i.e., hardware
independent) implementation of IEEE 802.11 encryption for WEP, TKIP, and
CCMP. These functions take in skb's with IEEE 802.11 headers and
encrypt/decrypt the frames. I haven't yet taken a look at your IPW2100
driver, but if you are including IEEE 802.11 headers in the skb's at
some point, I would assume that the WEP implementation from Host AP
driver would work fine with that driver, too.
The current implementation has hardware independent module (hostap.ko)
that exports the crypto functions for IEEE 802.11 skb's. Both client
station and AP is supported. (To be honest, there is probably still
couple of small Prism2-specific parts in hostap.ko, but not in the
crypto parts and I'm in the process of getting rid of the remaining
wlan hardware dependent parts).
I'm in the process of replacing the algorithm parts (RC4, Michael MIC,
AES-CCM) with crypto API versions so that only the IEEE 802.11 specific
parts (like format of the IV/packet number, replay protection,
pseudo-header for authentication) remain in the implementation and
low-level crypto algorithms can share code with other uses. Once this is
done, I would hope to get the code merged into the kernel tree either
with full Host AP driver or separately. One option would be to first add
Host AP driver in its current structure (i.e., everything in
drivers/net/wireless) and then create a new directory (net/ieee80211 ?)
for generic IEEE 802.11 functionality and start moving things like the
IEEE 802.11 encryption into the new location.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-11 2:31 ` Jouni Malinen
@ 2004-03-11 2:43 ` Jeff Garzik
2004-03-15 22:18 ` Pavel Machek
0 siblings, 1 reply; 33+ messages in thread
From: Jeff Garzik @ 2004-03-11 2:43 UTC (permalink / raw)
To: Jouni Malinen
Cc: James Ketrenos, jt, Christoph Hellwig, David S. Miller, netdev,
Linux kernel mailing list
Jouni Malinen wrote:
> done, I would hope to get the code merged into the kernel tree either
> with full Host AP driver or separately. One option would be to first add
> Host AP driver in its current structure (i.e., everything in
> drivers/net/wireless) and then create a new directory (net/ieee80211 ?)
> for generic IEEE 802.11 functionality and start moving things like the
> IEEE 802.11 encryption into the new location.
Given the discussion today, I think my preference is to merge all of
HostAP into the wireless-2.6 tree I just created, then submit patches to
that which create and populate net/802_11. Once the work on that is
mostly done, it can get merged back into the main upstream tree.
Jeff
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-11 2:43 ` Jeff Garzik
@ 2004-03-15 22:18 ` Pavel Machek
2004-03-15 22:44 ` Jeff Garzik
2004-03-15 22:55 ` Jean Tourrilhes
0 siblings, 2 replies; 33+ messages in thread
From: Pavel Machek @ 2004-03-15 22:18 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jouni Malinen, James Ketrenos, jt, Christoph Hellwig,
David S. Miller, netdev, Linux kernel mailing list
On St 10-03-04 21:43:08, Jeff Garzik wrote:
> Jouni Malinen wrote:
> >done, I would hope to get the code merged into the kernel tree either
> >with full Host AP driver or separately. One option would be to first add
> >Host AP driver in its current structure (i.e., everything in
> >drivers/net/wireless) and then create a new directory (net/ieee80211 ?)
> >for generic IEEE 802.11 functionality and start moving things like the
> >IEEE 802.11 encryption into the new location.
>
> Given the discussion today, I think my preference is to merge all of
> HostAP into the wireless-2.6 tree I just created, then submit patches to
> that which create and populate net/802_11. Once the work on that is
> mostly done, it can get merged back into the main upstream tree.
Can we have net/wifi? 802_11 looks ugly. 802.11 would be better, but
wifi seems best.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-15 22:18 ` Pavel Machek
@ 2004-03-15 22:44 ` Jeff Garzik
2004-03-15 22:55 ` Jean Tourrilhes
1 sibling, 0 replies; 33+ messages in thread
From: Jeff Garzik @ 2004-03-15 22:44 UTC (permalink / raw)
To: Pavel Machek
Cc: Jouni Malinen, James Ketrenos, jt, Christoph Hellwig,
David S. Miller, netdev, Linux kernel mailing list
Pavel Machek wrote:
> Can we have net/wifi? 802_11 looks ugly. 802.11 would be better, but
> wifi seems best.
That's fine, I'm not picky about it...
Jeff
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-15 22:18 ` Pavel Machek
2004-03-15 22:44 ` Jeff Garzik
@ 2004-03-15 22:55 ` Jean Tourrilhes
1 sibling, 0 replies; 33+ messages in thread
From: Jean Tourrilhes @ 2004-03-15 22:55 UTC (permalink / raw)
To: Pavel Machek
Cc: Jeff Garzik, Jouni Malinen, James Ketrenos, Christoph Hellwig,
David S. Miller, netdev, Linux kernel mailing list
On Mon, Mar 15, 2004 at 11:18:26PM +0100, Pavel Machek wrote:
> On St 10-03-04 21:43:08, Jeff Garzik wrote:
> > Jouni Malinen wrote:
> > >done, I would hope to get the code merged into the kernel tree either
> > >with full Host AP driver or separately. One option would be to first add
> > >Host AP driver in its current structure (i.e., everything in
> > >drivers/net/wireless) and then create a new directory (net/ieee80211 ?)
> > >for generic IEEE 802.11 functionality and start moving things like the
> > >IEEE 802.11 encryption into the new location.
> >
> > Given the discussion today, I think my preference is to merge all of
> > HostAP into the wireless-2.6 tree I just created, then submit patches to
> > that which create and populate net/802_11. Once the work on that is
> > mostly done, it can get merged back into the main upstream tree.
>
> Can we have net/wifi? 802_11 looks ugly. 802.11 would be better, but
> wifi seems best.
> Pavel
IEEE 802.11 is a technical standard. WiFi is a marketing
certification. There are 802.11 products which are not WiFi certified
(actually, there is one such driver already in the kernel).
By the way, I don't really care about the final name, I'm hust
being pedantic ;-)
Have fun...
Jean
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-10 17:58 ` Jeff Garzik
2004-03-10 23:37 ` James Ketrenos
@ 2004-03-11 2:48 ` Jouni Malinen
2004-03-11 3:02 ` Jeff Garzik
1 sibling, 1 reply; 33+ messages in thread
From: Jouni Malinen @ 2004-03-11 2:48 UTC (permalink / raw)
To: Jeff Garzik
Cc: jt, Christoph Hellwig, David S. Miller, netdev,
Linux kernel mailing list
On Wed, Mar 10, 2004 at 12:58:28PM -0500, Jeff Garzik wrote:
> So here is my suggested plan:
> * I merge prism54 upstream
> * I create wireless-2.6 queue
> * somebody (you, Jouni(sp?)) submits HostAP to me
> * I merge HostAP
Sounds good to me. I have the Kconfig/Makefile(etc.) patches ready and
the current CVS snapshot of Host AP driver supports 2.6.x kernel
versions, so in theory it is ready to be submitted.
When this topic came up some time ago, I got one concrete comment about
needed changes before the merge (I think it was from you) and that was
to replace the internal encryption algorithms with crypto API ones. I'm
currently in the process of doing this and submitting needed changes for
crypto API. WEP and TKIP have the needed parts as crypto API components
(RC4 is already in kernel tree, Michael MIC patch is pending). CCMP
requires some work (new encryption mode, counter with CBC-MAC, but AES
is already in crypto API).
What would be the preferred order for the HostAP submission? I'm
currently doing the crypto changes in the Host AP CVS repository, but I
can do this also in another repository since you mentioned a new
non-mainline queue for wireless-2.6. I have also some other cleanup
things in my to do list (like getting rid of 2.4 and old wireless
extensions compatibility code, because this would not be needed in the
kernel tree anymore). Again, this is currently proceeding in my CVS
repository, but it can also be done elsewhere, if that is desired.
I'm going to be at the IEEE 802.11 meeting for the next week which is
probably going to take more or less all of my time, but I should be able
to allocate more time after that. If people are interested in reviewing
the current Host AP code from the viewpoint of what would need to happen
before it can be merged into the kernel tree, the latest version is
available as a snapshot from my CVS tree (pserver or tarball) at
http://hostap.epitest.fi/. The current version is almost 20k lines, so
there is certainly quite a bit of code to review. I hope to get this to
about 15k lines, though, with the crypto API and backwards
compatibility cleanup.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-11 2:48 ` Jouni Malinen
@ 2004-03-11 3:02 ` Jeff Garzik
2004-03-11 3:17 ` Jouni Malinen
0 siblings, 1 reply; 33+ messages in thread
From: Jeff Garzik @ 2004-03-11 3:02 UTC (permalink / raw)
To: Jouni Malinen
Cc: jt, Christoph Hellwig, David S. Miller, netdev,
Linux kernel mailing list
Jouni Malinen wrote:
> I'm going to be at the IEEE 802.11 meeting for the next week which is
> probably going to take more or less all of my time, but I should be able
> to allocate more time after that. If people are interested in reviewing
> the current Host AP code from the viewpoint of what would need to happen
> before it can be merged into the kernel tree, the latest version is
> available as a snapshot from my CVS tree (pserver or tarball) at
> http://hostap.epitest.fi/. The current version is almost 20k lines, so
> there is certainly quite a bit of code to review. I hope to get this to
> about 15k lines, though, with the crypto API and backwards
> compatibility cleanup.
How about submitting a patch, when the CryptoAPI and backcompat cleanups
are complete? I will apply to the wireless-2.6 tree, and we can start
working on the kernel's overall 802.11 support from there. I don't
pretend to be an 802.11 expert, so I'll let you and Jean and other
developers drive that end of things. I'm mainly interested in keeping
the API simple and clean, and maintainable.
Jeff
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-11 3:02 ` Jeff Garzik
@ 2004-03-11 3:17 ` Jouni Malinen
2004-03-11 16:28 ` Device naming for wireless NICs James Ketrenos
0 siblings, 1 reply; 33+ messages in thread
From: Jouni Malinen @ 2004-03-11 3:17 UTC (permalink / raw)
To: Jeff Garzik
Cc: jt, Christoph Hellwig, David S. Miller, netdev,
Linux kernel mailing list
On Wed, Mar 10, 2004 at 10:02:20PM -0500, Jeff Garzik wrote:
> How about submitting a patch, when the CryptoAPI and backcompat cleanups
> are complete? I will apply to the wireless-2.6 tree, and we can start
> working on the kernel's overall 802.11 support from there.
OK, I'll do the cleanups in the Host AP CVS and submit the patch after
that. I'll make a new branch for this cleanup, so the changes will be
available there if people are interested in commenting the code before
the cleanup is complete.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply [flat|nested] 33+ messages in thread
* Device naming for wireless NICs...
2004-03-11 3:17 ` Jouni Malinen
@ 2004-03-11 16:28 ` James Ketrenos
2004-03-11 16:36 ` Tomasz Torcz
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: James Ketrenos @ 2004-03-11 16:28 UTC (permalink / raw)
Cc: netdev
If this topic been hashed a lot already, please let me know the keywords I might
search for in the archives to find the threads.
I've had a few requests by users of the IPW2100 wireless driver to switch the
default interface name to be wlanX vs. ethX. In my prior searches through the
wireless drivers in the 2.6.3 kernel tree, I couldn't find any that changed from
the default.
I don't mind adding a module parameter to change the default name (if that is
the standard practice), but thought I'd see what others thing rather than just
going off and doing something random.
Is there a technical or ease of use reason switching away from ethX? My
thinking in keeping it eth was that it then represents a greater chance of "just
working" with most networking scripts and utilities that may assume ethX is the
interface name.
Thanks,
James
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Device naming for wireless NICs...
2004-03-11 16:28 ` Device naming for wireless NICs James Ketrenos
@ 2004-03-11 16:36 ` Tomasz Torcz
2004-03-11 16:54 ` Matthew Galgoci
2004-03-11 18:23 ` Jeff Garzik
2 siblings, 0 replies; 33+ messages in thread
From: Tomasz Torcz @ 2004-03-11 16:36 UTC (permalink / raw)
To: netdev
On Thu, Mar 11, 2004 at 10:28:23AM -0600, James Ketrenos wrote:
> I don't mind adding a module parameter to change the default name (if that
> is the standard practice), but thought I'd see what others thing rather
> than just going off and doing something random.
This could be handled by nameif in userspace.
> Is there a technical or ease of use reason switching away from ethX? My
> thinking in keeping it eth was that it then represents a greater chance of
> "just working" with most networking scripts and utilities that may assume
> ethX is the interface name.
I personally find them broken. I had to remove checking the name from
ethtool to make it work. Ethtool checks for 'eth' or 'usb' in name,
which do not work with my e1000 renamed to 'ep0'.
--
Tomasz Torcz Only gods can safely risk perfection,
zdzichu@irc.-nie.spam-.pl it's a dangerous thing for a man. -- Alia
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Device naming for wireless NICs...
2004-03-11 16:28 ` Device naming for wireless NICs James Ketrenos
2004-03-11 16:36 ` Tomasz Torcz
@ 2004-03-11 16:54 ` Matthew Galgoci
2004-03-11 18:25 ` Jeff Garzik
2004-03-11 18:23 ` Jeff Garzik
2 siblings, 1 reply; 33+ messages in thread
From: Matthew Galgoci @ 2004-03-11 16:54 UTC (permalink / raw)
To: James Ketrenos; +Cc: netdev
On Thu, 11 Mar 2004, James Ketrenos wrote:
>
> If this topic been hashed a lot already, please let me know the keywords I might
> search for in the archives to find the threads.
>
> I've had a few requests by users of the IPW2100 wireless driver to switch the
> default interface name to be wlanX vs. ethX. In my prior searches through the
> wireless drivers in the 2.6.3 kernel tree, I couldn't find any that changed from
> the default.
>
> I don't mind adding a module parameter to change the default name (if that is
> the standard practice), but thought I'd see what others thing rather than just
> going off and doing something random.
>
> Is there a technical or ease of use reason switching away from ethX? My
> thinking in keeping it eth was that it then represents a greater chance of "just
> working" with most networking scripts and utilities that may assume ethX is the
> interface name.
TBH I don't think it much matters. I know that at least Red Hat's networking scripts
(and possibly other distributions) did at one point assume that each interface would
be named ethX, but I don't think that is the case anymore.
Some drivers even present both a wlanX and an ethX interface, which I think is an atavism
that goes back to networking scripts breaking horribly on non-ethX interface names.
Going forward it might be worth while to standardize all wireless interface names, just
to show at a glance that an interface is 802.11x, and also to differentiate the fact that
eventually 802.11 will be its own network stack.
--
Matthew Galgoci
System Administrator
Red Hat, Inc
919.754.3700 x44155
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Device naming for wireless NICs...
2004-03-11 16:54 ` Matthew Galgoci
@ 2004-03-11 18:25 ` Jeff Garzik
0 siblings, 0 replies; 33+ messages in thread
From: Jeff Garzik @ 2004-03-11 18:25 UTC (permalink / raw)
To: Matthew Galgoci; +Cc: James Ketrenos, netdev
Matthew Galgoci wrote:
> Going forward it might be worth while to standardize all wireless interface names, just
> to show at a glance that an interface is 802.11x, and also to differentiate the fact that
> eventually 802.11 will be its own network stack.
I definitely want to standardize on something like wlan%d. We should
get that for free when a generic 802.11 stack is in place, which implies
that there will be a common wireless helper as a peer to ether_setup()
in the current tree.
Jeff
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Device naming for wireless NICs...
2004-03-11 16:28 ` Device naming for wireless NICs James Ketrenos
2004-03-11 16:36 ` Tomasz Torcz
2004-03-11 16:54 ` Matthew Galgoci
@ 2004-03-11 18:23 ` Jeff Garzik
2004-03-12 10:30 ` P
2 siblings, 1 reply; 33+ messages in thread
From: Jeff Garzik @ 2004-03-11 18:23 UTC (permalink / raw)
To: James Ketrenos; +Cc: netdev
James Ketrenos wrote:
>
> If this topic been hashed a lot already, please let me know the keywords
> I might search for in the archives to find the threads.
>
> I've had a few requests by users of the IPW2100 wireless driver to
> switch the default interface name to be wlanX vs. ethX. In my prior
> searches through the wireless drivers in the 2.6.3 kernel tree, I
> couldn't find any that changed from the default.
I lean towards wlan%d, but until we have the generic 802.11 stack going
it's really up to the driver maintainer (you, in this case).
Like Matthew said, any code that assumes a specific interface prefix, be
it eth%d or wlan%d, is buggy. Users are allowed to choose random
interface names for their interfaces, often via nameif(8) program. My
own ethtool program is broken in this regard...
Jeff
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-10 17:21 ` Jean Tourrilhes
2004-03-10 17:29 ` Christoph Hellwig
2004-03-10 17:29 ` Jeff Garzik
@ 2004-03-10 18:07 ` Jeff Garzik
2004-03-11 2:21 ` Jouni Malinen
2004-03-10 22:17 ` Luis R. Rodriguez
3 siblings, 1 reply; 33+ messages in thread
From: Jeff Garzik @ 2004-03-10 18:07 UTC (permalink / raw)
To: jt
Cc: Christoph Hellwig, prism54-devel, David S. Miller, netdev,
Linux kernel mailing list
Jean Tourrilhes wrote:
> On Wed, Mar 10, 2004 at 04:55:48PM +0000, Christoph Hellwig wrote:
>
>>On Wed, Mar 03, 2004 at 06:35:24PM -0800, Jean Tourrilhes wrote:
>>
>>> Hi Dave & Jeff,
>>>
>>> The attached .bz2 file is a patch for 2.6.3 adding the
>>>Intersil Prism54 wireless driver. Sorry for the attachement, the file
>>>is rather big, if you want inline+plaintext, I'll send that personal
>>>to you.
>>> I've been using this driver with great success on 2.6.3 and
>>>2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
>>>802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
>>>chipset.
>>> I would like this driver to go into 2.6.X. However, I
>>>understand that it's lot's of code to review.
>>
>>Here's a few things I found.
>
>
> I'm forwarding to prism54-devel where the real developpers can
> answer your questions.
since I'm not on the this list, I am getting a bunch of "your message
for prism54-devel awaits moderator approval" responses.
Maybe the prism54 and hostAP developers could join us on netdev? It
would be nice to have everybody in one place, if we're all gonna be
collaborating on a generic 802.11 stack.
Jeff
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-10 18:07 ` [PATCH 2.6] Intersil Prism54 wireless driver Jeff Garzik
@ 2004-03-11 2:21 ` Jouni Malinen
0 siblings, 0 replies; 33+ messages in thread
From: Jouni Malinen @ 2004-03-11 2:21 UTC (permalink / raw)
To: Jeff Garzik
Cc: jt, Christoph Hellwig, prism54-devel, David S. Miller, netdev,
Linux kernel mailing list
On Wed, Mar 10, 2004 at 01:07:17PM -0500, Jeff Garzik wrote:
> Maybe the prism54 and hostAP developers could join us on netdev? It
> would be nice to have everybody in one place, if we're all gonna be
> collaborating on a generic 802.11 stack.
I am (and have been for quite a while) on netdev, so as far as anything
related to IEEE 802.11 stack or Host AP driver is concerned, I certainly
do follow netdev list, too.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Re: [PATCH 2.6] Intersil Prism54 wireless driver
2004-03-10 17:21 ` Jean Tourrilhes
` (2 preceding siblings ...)
2004-03-10 18:07 ` [PATCH 2.6] Intersil Prism54 wireless driver Jeff Garzik
@ 2004-03-10 22:17 ` Luis R. Rodriguez
3 siblings, 0 replies; 33+ messages in thread
From: Luis R. Rodriguez @ 2004-03-10 22:17 UTC (permalink / raw)
To: jt
Cc: Christoph Hellwig, prism54-devel, David S. Miller, Jeff Garzik,
netdev, Linux kernel mailing list
[-- Attachment #1: Type: text/plain, Size: 4381 bytes --]
On Wed, Mar 10, 2004 at 09:21:14AM -0800, Jean Tourrilhes wrote:
> On Wed, Mar 10, 2004 at 04:55:48PM +0000, Christoph Hellwig wrote:
> > On Wed, Mar 03, 2004 at 06:35:24PM -0800, Jean Tourrilhes wrote:
> > > Hi Dave & Jeff,
> > >
> > > The attached .bz2 file is a patch for 2.6.3 adding the
> > > Intersil Prism54 wireless driver. Sorry for the attachement, the file
> > > is rather big, if you want inline+plaintext, I'll send that personal
> > > to you.
> > > I've been using this driver with great success on 2.6.3 and
> > > 2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
> > > 802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
> > > chipset.
> > > I would like this driver to go into 2.6.X. However, I
> > > understand that it's lot's of code to review.
> >
> > Here's a few things I found.
>
> I'm forwarding to prism54-devel where the real developpers can
> answer your questions.
>
> > It's not exactly a full review, there's
> > too much new snow to spend lots of time in front of a computer here :)
>
> Grrr... This year, no snow for me.
>
> > diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.6.3/drivers/net/wireless/prism54/Makefile linux-2.6.3-prism54/drivers/net/wireless/prism54/Makefile
> > --- linux-2.6.3/drivers/net/wireless/prism54/Makefile Thu Jan 1 00:00:00 1970
> > +++ linux-2.6.3-prism54/drivers/net/wireless/prism54/Makefile Thu Mar 4 02:00:01 2004
> > @@ -0,0 +1,10 @@
> > +# $Id: Makefile.k26,v 1.7 2004/01/30 16:24:00 ajfa Exp $
> > +
> > +prism54-objs := islpci_eth.o islpci_mgt.o \
> > + isl_38xx.o isl_ioctl.o islpci_dev.o \
> > + islpci_hotplug.o isl_wds.o oid_mgt.o
> >
> > please use foo-y for new drivers.
TODO
> >
> > +
> > +obj-$(CONFIG_PRISM54) += prism54.o
> > +
> > +EXTRA_CFLAGS = -I$(PWD) #-DCONFIG_PRISM54_WDS
> >
> > This is bogus, especially with srcdir != objdir.
> > please fixup the includes instead
> >
> > +#define __KERNEL_SYSCALLS__
> >
> > this shouldn't be used anymore.
Done
> >
> > +
> > +#include <linux/version.h>
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/delay.h>
> > +
> > +#include "isl_38xx.h"
> > +#include <linux/firmware.h>
> > +
> > +#include <asm/uaccess.h>
> > +#include <asm/io.h>
> >
> > Please include headers in the following order <linux/*.h>,
> > <asm/*.h>, driver-specific.
Done
> >
> > +#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,5,75))
> > +#include <linux/device.h>
> > +# define _REQ_FW_DEV_T struct device *
> > +#else
> > +# define _REQ_FW_DEV_T char *
> > +#endif
> >
> > Eeek, why don't you simply pass the pci_dev down?
TODO
> >
> >
> > +typedef struct isl38xx_cb isl38xx_control_block;
> >
> > No useless typedefs please.
> >
> > +MODULE_PARM(init_mode, "i");
> > +MODULE_PARM_DESC(init_mode,
> > + "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client (Default)\n3: Master / Access Point\n4: Repeater (Not supported yet)\n5: Secondary (Not supported yet)\n6: Monitor");
> >
> > Please use module_param
Done
>
> I would even say that this is useless because the driver
> support WE, and WE scripts set the mode before the card is up.
True, we can just remove the param for iw_mode.
>
> > diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c
> > --- linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c Thu Jan 1 00:00:00 1970
> > +++ linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c Thu Mar 4 02:00:01 2004
> >
> > WDS doesn't belong into a driver but in higher-level code.
The driver features some firmware-specific WDS functionality, such as
adding/removing WDS links. We haven't looked much into it yet though since
it's not high priority. Where exactly should this code go to then?
Elements noted as DONE were just committed into our CVS repository. You
can always find our latest 2.6 kernel patch at:
http://prism54.org/pub/linux/snapshot/kernel/v2.6/patch-2.6-prism54-cvs-latest.bz2
FWIW, the same driver code base supports 2.4:
http://prism54.org/pub/linux/snapshot/kernel/v2.4/patch-2.4-prism54-cvs-latest.bz2
Luis
--
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread