On Mon, 2008-09-15 at 21:46 +0200, Johannes Berg wrote: > On Mon, 2008-09-15 at 21:39 +0200, Mattias Nissler wrote: > > > > Yes, but we could also make the ack queue processing part of mac80211, > > > i.e. we stick the packet on the queue before ->tx() and add a few new > > > flags to the status callback which can then process the queue. > > > > Just to get this straight: By queue you mean the to-be-introduced > > unknown status queue? > > Yes. > > > Of course you can do it that way, but then you'll have all the flags and > > data structures built into mac80211 unconditionally instead of letting > > the driver developer decide. > > Oh, I'm fine with building them in there as long as the code paths > aren't actually used for drivers that don't need them. This isn't a big > thing. Well, I'm a big fan of modularizing everything in a clean way. This whole mac80211 thingy is complex enough... But I don't really care as long as everybody here is happy with it. Let's wait what Mikko says, it's his code so far. > > > > > Good point :-) So I suggest we have one function that adds new packets > > > > to the ACK queue (which is represented by a struct an instance of which > > > > a driver can keep in its queue information) and another one that matches > > > > a received ACK with the queue, reports the status to mac80211 and purges > > > > the queue entries up to the match (reporting them as failed). > > > > > > can we stop talking about "ACK queue"? It really is a "unknown status > > > queue" or something like that. > > > > Ok, I don't really care how it's called as long as the one writing that > > stuff chooses an appropriate name in the code :-) > > :) > But ACK is getting confusing, we're just reporting status based on > reception (or non-reception!) of ACKs :) How about retries in the hw? Retries in the hw? I don't understand? You mean that as a name? Mattias -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
