Subject: Re: generic 802.11 stack

From: Vladimir Kondratiev <[email-masked]>
Date: Sat, 2 Oct 2004 01:25:32 +0200

On Saturday 02 October 2004 00:53, David S. Miller wrote:
DS>
DS> Why this change?
DS>
DS> -extern void hh_data_is_too_small(void);
DS> +static void hh_data_is_too_small(void)
DS> +{
DS> +    printk(KERN_ERR "hh_data_is_too_small\n");
DS> +}

My misunderstanding. Sorry.

DS>
DS> We don't define the function because it is meant to
DS> cause a compile time error if hh->hh_data is too small to
DS> hold the full p80211_data_header structure.  Please undo
DS> this change.
DS>
DS> And therefore undo this change too:
DS>
DS> - if (sizeof(hh->hh_data) < sizeof(*p))
DS> + if (sizeof(hh->hh_data) < sizeof(*p)) {
DS>    hh_data_is_too_small();
DS> +        return -1;
DS> +    }

As above.

DS>
DS> Next, what's this?
DS>
DS> - dev->hard_header = p80211_header;
DS> + dev->hard_header     = p80211_header;
DS>   dev->rebuild_header  = p80211_rebuild_header;
DS>
DS> Your merely changing the tab character after dev->hard_header
DS> into spaces.  Please don't do this.  This makes a lot of white
DS> space noise when making diffs against the original davem-p80211
DS> code thus making it harder to review the changes you actually made.

My editor did it for me. I'll be more carefull to check this behind the scene 
things. Maybe, I'll do one patch to do all spaces accordingly to kernel 
coding style, and since that will follow it.

DS>
DS> Next:
DS>
DS> +    dev->mtu                = 2304;
DS> +    dev->type               = ARPHRD_IEEE80211;
DS>
DS> Is this really the correct default MTU for wireless devices?

Yes, 802.11e (QoS) defines this value.

DS>
DS> @@ -342,7 +343,7 @@ int p80211_recv_cfackpoll(struct sk_buff
DS>  static struct packet_type p80211_packet_type = {
DS>   .type = __constant_htons(ETH_P_802_11),
DS>   .func = p80211_rcv,
DS> - .data = (void *) 1, /* understands shared SKBs */
DS> + .af_packet_priv = (void *) 1, /* understands shared SKBs */
DS>  };
DS>
DS> You can just remove this line entirely for 2.6.x kernels.

Thanks, I will. I was confused by this member and did simplest trick to make 
it compile.

DS>
DS> Otherwise looks fine :-)

Really, thus far I did almost nothing. It is just foundation for playing with 
stack. My intention was to decouple driver and stack ASAP to enable separate 
development for each part.

Next step I will do data path, with some code to enable QoS 26 byte headers 
but without real QoS, which is, by the way, pretty complicated as defined in 
TGe. May be, it is better to start with WME w.r.t QoS.

Then, it is management's turn. Association, scanning.

Then, once again, data path. Fragmentation, reassembly. Framework for 
security.

Then - let's see how this will develop.