There is IPv6 code too, assumes the existence of arpcom. So I suggest to revert this commit. If you do want to get rid of arpcom, we will have to make the stack change first; instead of starting from drivers.
IFP2AC() == cast ifnet to arpcom. Thanks, sephe On Tue, Jul 17, 2018 at 4:57 PM, Aaron LI <[email protected]> wrote: > Hi sephe, > > Thanks for pointing out the problem, but I don't understand it fully yet. > > Should I revert this commit, or continue to fix the related things? > > (1) The tap interface can be created correctly, and its MAC address is > printed on console, so the 'ether_ifattach()', which calls > 'ether_ifattach_bpf()', works as expected. Is this you expected? > > (2) I think the problem you refer to is the following code in > 'ether_ifattach_bpf()': > > 621 /* > 622 * XXX Keep the current drivers happy. > 623 * XXX Remove once all drivers have been cleaned up > 624 */ > 625 if (lla != IFP2AC(ifp)->ac_enaddr) > 626 bcopy(lla, IFP2AC(ifp)->ac_enaddr, ifp->if_addrlen); > > I don't understand how the 'IFP2AC(ifp)->ac_enaddr' works? On which > conditions can we do 'struct type casting'? > > (3) As the above 'XXX' comments say, how to clean up the drivers? Will it be > complicated? I can work on this. > > Cheers, > -- > Weitian > > > On Tue, 17 Jul 2018 16:16:58 +0800 > Sepherosa Ziehau <[email protected]> wrote: > >> You are breaking the ether_ifattach() of the tap interface; last time >> I checked, this will break IPv6 stuff too, which assume the existence >> of arpcom. >> > -- Tomorrow Will Never Die
