On Fri, 3 Feb 2006 13:08:17 -0800 "Simon Barber" <[EMAIL PROTECTED]> wrote:
> Currently many wireless drivers handle SNAP->Ethernet header processing > - this is an obvious candidate for factoring out - and might possibly be > something that should be moved out of the wireless code completely. > Would it make sense to add the code to eth_trans_type or create a > ieee80211_trans_type? > > Advantages: > 1) Better code reuse > 2) Frame data is no longer moved or touched unless bridging. > > Disadvantage: > 1) things like dhcpd need to understand SNAP header format (unless > frames going to a raw socket have the header re-written) > 2) bridge code needs to rewrite frames according to the output port's > needed header type > > Comments? Suggestions? > > Simon We already have a snap processor, so why not just do a netif_receive_skb on the frame. You need to select LLC in the kernel config with that driver. -- Stephen Hemminger <[EMAIL PROTECTED]> OSDL http://developer.osdl.org/~shemminger - 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
