On Monday 05 February 2007 18:43, Ivo van Doorn wrote: > On Monday 05 February 2007 18:28, Jiri Benc wrote: > > On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote: > > > Not all hardware are capable of generating their own RTS frames. > > > This patch will add support for creating the RTS frame in software, > > > when the driver requests this through the flag > > > IEEE80211_HW_SOFTWARE_RTS > > > > It seems this is not the ideal solution. Most of drivers needing > > software RTS would need to remember the RTS frame somewhere (as they > > need to pass it together with the actual frame). > > Well in case of rt2x00 (I am not sure which other drivers also need software > RTS) > the rts packet is just inserted inside the packet ring and is treated as a > regular > packet/fragment that has just been inserted by the driver. > > This patch just adds this additional packet just before the real packet, and > in case > the real packet could not be send the rts packet is stored in the > ieee80211_tx_stored_packet structure to be send later.
Ok, I see. But this is not going to work with bcm43xx. I also sent a fix for rt2x00 to work with my patchset. > > A better solution would be either to pass a pointer to RTS frame data > > in tx_control or to create a function returning RTS frame. > > In case of rt2x00 this would deliver more problems, especially since it will > use > a ring entry to send the rts frame and in case of rt2500usb and rt73usb it > will > need a sk_buff structure since it needs to pass it to the device (where the > sk_buff > will have some free tx_header_room for the descriptor.) I don't understand this. You need to put in into the ring either way. See my patch. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
