On Fri, Feb 23, 2007 at 01:49:47PM +0200, Markku Savela wrote: > The IPv6 and IPv4 both seem to be rather akwardly hardcoded to support > only link layers they know. > > This is a pity, because it would be so easy to make the both stacks > totally independent of the actual link layers. It only needs one (or > two) new function pointer in net_device. This function should do the > conversion from IPv4/IPv6 address into corresponding hardware > multicast/broadcast address. > > In both IPv4 and IPv6, all places where symbols ARPHRD_* are > reference, are suspect (there are some related to tunnels, which may > be appropriate). For example, in ipv4/arp.c arp_mc_map would call this > mapping function, if provided. Similarly ipv6/ndisc.c ndisc_mc_map. > > In ipv6/addrconf.c the ivp6_generate_eui64 may possibly need yet > another netdev function provided by the driver. > > The current Ethernet specific code for these mappings could be moved > from the ipv6/ipv6 into eth.c, and ether_setup would give defaults for > the functions. > > [I run into this while trying to do a netdev to a device is not known > by the stacks, and IPv6 even refuses to start on it (because of the > ivp6_generate_eui64 fails?). IPv4 ARP seems to fall back to broadcast, > so it sort of starts] >
patches welcome :) > -- > Markku Savela > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/