On Monday 05 February 2007 19:07, Ivo van Doorn wrote:

Hi,

quoted

quoted

quoted

quoted

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.

Did you already send that patchset to the netdev list?
Because I haven't seen a patch series about rts for d80211 yet.

No, linux-wireless@vger.kernel.org

The new rt2500usb and rt73usb packet ring handling no longer use a DMA buffer
but instead send the sk_buffer->data pointer to the USB layer.
The solution as suggested by Jiri could be handled by making sure the rts allocated
buffer will also have a tx header room as set in the tx_header_room field. But I am not
sure if that would be a better solution than putting the rts packet in a sk_buffer that is being
send out just before the real packet...

In my patchset you can put it into anything you like.
I put it into an skb.

-- 
Greetings Michael.