Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> This patch adds te IOCTL request IOC_RT_HOST_ROUTE_RESOLVED to check >> if an IPv4 host address has been resolved. A timeout can be specified >> to await the address resolution (ARP reply). The rtroute utility >> supports this request and serves as example: >> >> # rtroute solicit <addr> dev <dev> [wait <ms>] > > I'm fine with the general purpose of this extension, but I do not yet > like the way it is designed in details. > > Why do we have to push the polling loop into kernel space? I don't see a > valid reason for this. What about making the new service even more > useful and defining it as "get host route", ie. make it deliver the > related route or an error if it is not resolvable. Polling can take > place at application/tool level IMHO.
The request IOC_RT_GET_HOST_ROUTE was my first idea as well, but than I decided to restrict to the functionality I really need, including polling. Do you have a use-case in mind justifying an IOC_RT_GET_HOST_ROUTE request. Wolfgang. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
