On Wed, Mar 03, 2004 at 05:28:30PM -0500, Pavel Roskin wrote: > Hello! > > I believe the developers of Linux wireless drivers need a separate mailing > list, preferably called linux-wireless at vger.kernel.org. I don't expect > it to have heavy traffic, but there should be a definitive forum for > discussing issues common for wireless drivers on Linux. Hi Pavel, We meet again ;-) I appreciate all the effort you are putting into this. Let me tell you how I see the situation. There is a saying : "you can lead a horse to the water, but you can't force it to drink". Maintainer of wireless driver have never really felt part of the Kernel. Maybe it's a consequence of the loose and distributed development model of Linux (compared to *BSD), but most wireless driver are seen as standalone projects. This is not specific to wireless, it happens also for network driver. Do I need to mention Donald Becker ? However the Kernel people have been very aggressive into assimilating those drivers into the kernel (Jeff is doing a great amount of work on that). So, you may say it's a failure on people like myself to be more agressive in pushing those drivers in the kernel. Why does this matter ? If those driver maintainers don't feel part of the Kernel, they probably won't feel part of the "Linux wireless driver" group that you are trying to create. Those maintainers are already busy with bug reports and users. They would need a good incentive too coordinate such activities across drivers. Fortunately, those maintainers know about the common good and always take the path of least resistance. If someone provide the infrastructure, they will eventually buy into it. Actually, the new developpers are more likely to use it than those who already have working solutions. Look at the firmware download support. Manuel did a good job of talking with the various driver authors and come up with a useful solution, and it's a great success. Coming back to your point. It seems to me that what we need is motivated people willing to push specific cross-driver activities and coordinate those with the driver maintainers. The mailing list you propose may help those people to acheive their goal. But, without such people, it probably won't take off, because driver maintainers are just too busy. But, of course, I would be happy to be wrong ;-) > I expect following topics to be discussed: > > Wireless Extensions. I highly respect Jean Tourrilhes who is doing this > work. I believe that driver and userspace developers should use this > forum to discuss their needs and to provide feedback to Jean. I can tell you already : WPA. > Handling of 802.11 frames. We may need common code to convert 802.11 > frames to 802.3 and possibly other standards. Maybe some standards for > 802.11 encapsulation and bridging could be discussed as well. Yes, this is a sore point. Rather than starting from scratch I believe you should start from code in an existing driver (such as HostAP or MadWifi). Note that there are two separate parts, support of 802.2 (all the SNAP encapsualtion business), which is also useful for 802.3 networks, and support of 802.11 framing. I believe that Arnaldo was working on 802.2 support (as part of IPX stuff). Actually, you remind me that I should ask Jouni to push his driver in the kernel. > Sniffing. We need a common standard how to pass raw frames and additional > information to the userspace. There are several de facto standards, but > the lack of communication between developers makes those standards less > useful. For example, Prism2 headers were meant as highly extensible, but > libpcap expects them to be of fixed size. It's an obvious failure to > communicate the intentions of the standard. Software never get it right on the first try. That's a bug report on libpcap. If you break libpcap, they will notice soon enough. > Encryption. There are wireless specific encryption issues. Host based > WEP support needs RC4 cipher in the kernel. There's not much to discuss > here, but the lack of RC4 in the kernel may indicate that Linux wireless > developers are not acting together to make it happen. The patch does > exist. I've never seen this patch. Was it sent to the Crypto guys ? > Other interfaces between drivers and the userspace. There should be one > place to discuss whether wireless drivers should be using > netif_carrier_on/off, ethtool and mii-tool support. Again, there is not > much to discuss, but it's much much worse if the same questions are > discussed in different forums and every driver takes its own approach. Ethtool is a pet project of Jeff and he is pushing it quite actively. I actually was quite surprised to see it happening in wavelan_cs which is obsolete and has few users. > I believe linux-net@vger.kernel.org is the right place to ask because > Wireless almost inevitably assumes networking. I'll appreciate if > somebody with enough weight in the kernel development supports this issue. > Or at least please let me know where else I should ask and whose support I > need to have. Don't get me wrong, I'm supportive, I just wanted to set a bit of context. I can't host mailing lists at HP, and SourceForge is not really reliable. > Regards, > Pavel Roskin Good luck... Jean - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
