On Wed, 2007-01-17 at 12:43 -0500, Dan Williams wrote: > I said "mostly" fullmac. Sort of like ipw2100 (IIRC) is softmac but it > does all the association stuff in firmware. It doesn't fit fullmac, but > it's a lot more fullmac than atheros. There isn't any management frame > processing, it doesn't do any data frame processing.
Right. I hadn't looked at data frames but suspected this is the case. > The 8388 architecture is typical of a thick firmware architecture, where > the firmware handles all 802.11 MAC management tasks. The host driver > downloads standard 802.3 frames to the firmware to be transmitted over > the link as 802.11 frames. > > I thought these 2 things were essentially _the_ definition of fullmac, > please correct me if I'm wrong. Well we'll need more terms here. I had a short chat with Jouni and we agree that what the Marvell card is doing is exposing the MLME interface, and what d80211 is doing is implementing most of the MLME. I guess the thing I'm saying is that exposing the MLME interface which changes fairly frequently is a bad thing and I'd love to have firmware that exposes lower level stuff like . > Perhaps I just don't understand how flexible d80211 has become; when we > last were talking about it 8 months ago, it appears that it could not > handle parts that did significant pieces of work in firmware, like the > 8388 does. Do we have the functionality in d80211 yet to handle pieces > that are a full mix of hybrid full/soft mac? No, we don't have that yet, and we might never have. But I think I'm starting to understand the issues at hand a bit better and it seems that we'll need cfg80211 to be redefined. > 1) What, if any of this, could actually fit into the d80211 stack, given > the mostly fullmac operations of this part? Can we rephrase this in terms of the MLME interface etc that the 802.11 standard speaks about? That'd be easier I think. > 3) Could you enumerate your issues with the command dispatching? Right > now, many of the commands are blocking, which is suboptimal. This is an > artifact of the embedded history of the part. We need to eventually fix > that and make the upper layers not expect to block stuff like auth/assoc > and scanning. What other stuff are you thinking of? Well, one thing is that the whole command processing goes through a single function for no real benefit. You're basically saying command(...,CMD_NUM,...) and in command() you do switch(cmd_num) and multiplex it to a lot of functions again. I suppose I'd rather it called the functions directly and those in turn called the little common code there is in the dispatch routine. johannes
signature.asc
Description: This is a digitally signed message part
