On Fri, Jun 30, 2017 at 08:44:36AM +0200, Richard Cochran wrote: > On Fri, Jun 30, 2017 at 08:18:15AM +0200, Richard Cochran wrote:
> > request.hdr.nlmsg_type = RTM_GETLINK; > > - request.hdr.nlmsg_flags = NLM_F_REQUEST | NLM_F_DUMP; NLM_F_DUMP flag call function rtnl_dump_ifinfo(), which will dump all interface info. > > + request.hdr.nlmsg_flags = NLM_F_REQUEST; NLM_F_REQUEST call rtnl_getlink() which get exactally the interface's info. There is no much change for these two functions since v3.0. > > What about portability on older kernel versions? We need to run on > kernels starting with v3.0. The rtnetlink(7) man page says: > > ifi_flags contains the device flags, see netdevice(7); ifi_index > is the unique interface index (since Linux 3.7, it is possible > to feed a nonzero value with the RTM_NEWLINK message, thus cre‐ > ating a link with the given ifindex); ifi_change is reserved for Before v3.7 we do not support create interface with given ifindex with RTM_NEWLINK message[1]. Since we only need to get the interface info. It should be safe to use ifinfomsg on kernel v3.0 But with your remind. I found we start to support bond rtnetlink message from kernel v3.13. So before v3.13, we could not get slave info and ptp4l with bond interface will fail with error not support when check ts info. I think this should be OK with document "bond fail over support start with kernel v3.13". What do you think? > future use and should be always set to 0xFFFFFFFF. > > At that time, I added one extra FD into clock->pollfdp[], and the > > clock then farms out the information to the ports. I really did not > > to do it that way. A better way would have been to add a new per-port > > FD into fd.h, something like this: > > I meant to say, "I really did not want to do that way." > > I can't remember whether I even knew about the possibility of using > ifinfomsg.ifi_index to bind to a particular interface. At the time, I > either overlooked it or I might have rejected this because of lack of > portability to kernels before v3.7. > > In any case, kernel v3.7 is getting pretty old, and so I think we can: > > 1. remove the rtnl socket from clock.c > > 2. add one rtnl socket per port. > > 3. use ifinfomsg on kernel 3.7+ OK, I think we need a separate patch set to improve this. > > 4. fall back to rtgenmsg on kernel 3.0 - 3.6 (only if needed). And we do not need to concern about this issue now, right? > > Q: What is the behavior of pre 3.7 kernels WRT ifinfomsg.ifi_index? > If ifi_index is non-zero, does the kernel return EINVAL, or do > you get information from all interfaces? > > The only drawback is that, when running on earlier kernels, ptp4l will > duplicate work, handling all those per-port rtnl messages. But this > is acceptable if we can improve the ptp4l code for the future. > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/rtnetlink.c?h=v3.0#n1728 Thanks Hangbin ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
