Yes, fully agreed - and the hardware's pre-beacon interrupt would cause the beacon function to create a beacon frame and put it into the queue (dev_queue_xmit on the master device). The beacon frame would the be passed to the hardware through the normal run_queue that follows.
Simon -----Original Message----- From: Jouni Malinen Sent: Wednesday, March 15, 2006 4:48 PM To: Simon Barber Cc: Jiri Benc; netdev@vger.kernel.org Subject: Re: [RFC/PATCH 6/13] d80211: remove obsolete stuff On Wed, Mar 15, 2006 at 04:41:56PM -0800, Simon Barber wrote: > The more natural way for beacons to flow from the 80211.o to the low > level driver would be for beacons to be passed down just like any > other > 802.11 frame is passed down - rather than having a special case for > beacons and buffered MC data, where they are pulled. I would suggest > making the qdisc aware of beacons, and then there is no special > interface for passing beacons down - they are passed down just like > other frames, with a special queue ID reserved for beacons and > buffered multicast. > > This would simplify the 80211.o/low level interface. Sure, but it would also require good synchronization for sending the beacons just before they are needed for transmission.. If the wlan hardware implementation provides support for interrupts that request beacons at proper times, being able to use them for this is quite convenient. -- Jouni Malinen PGP id EFC895FA - 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
