Networking mailing list

On 2009-11-24 at 10:03:19 [+0100], Colin Gnther coling@xxxxxx wrote: I'd like to create a Branch for the wlan stack development. Mainly so that you guys can easier watch over my shoulders. I'd like to know whether this is OK, and if so whether there are any rules/guidelines I should following when branching. That's definitely OK. Just create the directory haiku/branches/developer/colin (relative to the repository root) and do whatever you want in it. The usual approach is to just copy the trunk as a ...

Hi, I'd like to create a Branch for the wlan stack development. Mainly so that you guys can easier watch over my shoulders. I'd like to know whether this is OK, and if so whether there are any rules/guidelines I should following when branching. Kind Regards -Colin ...

Colin Gnther coling@xxxxxx wrote: Axel Drfler schrieb: On the ioctl() level, I wouldn't mind keeping the (Free)BSD naming scheme, as we already have a more or less BSD compatible stack, and I see little point in differing there just for the sake of it. If this (Free)BSD compatiblity is one of the goals I have no problem with sticking to the IEEE80211 naming scheme. This goal wasn't so clear to me, so thanks for pointing it out. ...

For source compatibility with (future) ported software, I'm against renaming it. But nobody forbid us to add an alias, though: #define IFM_WIFI IFM_IEEE80211 So I'll stick with IFM_IEEE80211. I would exclude IFM_WIFI because of it beeing a name mainly used for official Wi-Fi alliance approved hardware. And I don't like the idea of claiming Wi-Fi compatibility without going through the required certification process. ...

philippe.houdoin@xxxxxxx schrieb: Hi Philippe, Hi Colin, Neither WLAN, WAN or LAN are media. They're network topology terms. When they're used in documents, they refer the topology part, not the media supporting them (even if often it's a given). Okay that's the way media is interpreted in the IFM_XXX context. ...

Axel Drfler schrieb: On the ioctl() level, I wouldn't mind keeping the (Free)BSD naming scheme, as we already have a more or less BSD compatible stack, and I see little point in differing there just for the sake of it. If this (Free)BSD compatiblity is one of the goals I have no problem ...

Hi Colin, Would it be okay to rename constants like IFM_IEEE80211 (and similar ones) to a less cryptical IFM_WLAN? I personally dislike this cryptical naming scheme as it makes visually parsing of the source code harder. WLAN is as qualified as ETHER which is used for the wired lan components. And WLAN is used in the IEEE 802.11 standards, too. Neither WLAN, WAN or LAN are media. They're network topology terms. When ...

Colin Gnther coling@xxxxxx wrote: Would it be okay to rename constants like IFM_IEEE80211 (and similar ones) to a less cryptical IFM_WLAN? I personally dislike this cryptical naming scheme as it makes visually parsing of the source code harder. WLAN is as qualified as ETHER which is used for the wired lan components. And WLAN is used in the IEEE 802.11 standards, too. ...

Would it be okay to rename constants like IFM_IEEE80211 (and similar ones) to a less cryptical IFM_WLAN? I personally dislike this cryptical naming scheme as it makes visually parsing of the source code harder. WLAN is as qualified as ETHER which is used for the wired lan components. And WLAN is used in the IEEE 802.11 standards, too. I know that FreeBSD is using the IEEE80211 naming scheme, but I don't see any valid reason for just copying it over. I'm open for other ...

Colin Gnther coling@xxxxxx wrote: I would like to know, whether there really is no implementation of the llc-layer (as specified in IEEE 802.2) in the network stack atm. At least I couldn't detect the code which adds llc-header data when processing net_buffers. There is indeed none. I would just add it to the ethernet_frame modul, as that would fit best with the current implementation; the current ethernet_deframe() doesn't even check for the frame type yet, it just ...

Hi, I would like to know, whether there really is no implementation of the llc-layer (as specified in IEEE 802.2) in the network stack atm. At least I couldn't detect the code which adds llc-header data when processing net_buffers. Kind Regards Colin ...

Axel Drfler schrieb: Colin Gnther coling@xxxxxx wrote: Would the API exposed to the drivers will be very different when you have developed the Haiku specific wifi stack? I am The Haiku specific WiFi API will be very different from the FreeBSD ...

Colin Gnther coling@xxxxxx wrote: Would the API exposed to the drivers will be very different when you have developed the Haiku specific wifi stack? I am The Haiku specific WiFi API will be very different from the FreeBSD one. For example: FreeBSDs WiFi driver interacting very closely with the WiFi stack. The Haiku stack will be more loosely coupled by relying on ioctls. ...

Dhruwat Bhagat schrieb: Hi Colin, do you think I could try porting the current freebsd driver for RALink to the current framework you have developed? At the moment I don't suggest to use any of my work directly, because it is only a prototype. Would the API exposed to the drivers will be very different when you have developed the Haiku specific wifi stack? I am ...

Hi Colin, do you think I could try porting the current freebsd driver for RALink to the current framework you have developed? Would the API exposed to the drivers will be very different when you have developed the Haiku specific wifi stack? I am currently trying to understand your work and the FreeBSD Compatibility layer. I am trying to see if the RALink driver can leverage your port like the Atheros FreeBSD driver does. cheers, Dhruv ...

Dhruwat Bhagat schrieb: Hi, I have an RALink 2571 based Dlink DWA-110 usb wifi adapter. I want to know if someone has written or is in the process of writing or porting a driver for it. I would like to work on porting an existing driver from another operating system to Haiku. So I want to know anyone else has started working on this task because if not, then I would want to start working on this. ...

Hi, I have an RALink 2571 based Dlink DWA-110 usb wifi adapter. I want to know if someone has written or is in the process of writing or porting a driver for it. I would like to work on porting an existing driver from another operating system to Haiku. So I want to know anyone else has started working on this task because if not, then I would want to start working on this. Cheers, Dhruv aka unitedroad ...

Romain romain.haiku@xxxxxxxxxxx wrote: Sorry, I intended to answer that one, it just got buried under a lot of other mails. No problem, i just feared it got lost because there was quite a lot of posts this week. Not lost, but sometimes I need so much time to answer, it has pretty much the same outcome... so any reminder is welcome! ...

Sorry, I intended to answer that one, it just got buried under a lot of other mails. No problem, i just feared it got lost because there was quite a lot of posts this week. I tried to move the Add call to the net_socket_private constructor, and then I felt in the problem of my previous email ...

Hi Romain, Romain romain.haiku@xxxxxxxxxxx wrote: This list may be more accurate for my issue since I had no answer on the devel mailing-list. Sorry, I intended to answer that one, it just got buried under a lot of other mails. ...