BTW, it's probably worth highlighting these parts of this patch:

First off, ip_dev_find() is exported again:

 > --- linux-2.6.git/net/ipv4/fib_frontend.c    2006-01-16 10:28:29.000000000 
 > -0800
 > +++ linux-2.6.ib/net/ipv4/fib_frontend.c     2006-01-16 16:14:24.000000000 
 > -0800
 > @@ -666,4 +666,5 @@ void __init ip_fib_init(void)
 >  }
 >  
 >  EXPORT_SYMBOL(inet_addr_type);
 > +EXPORT_SYMBOL(ip_dev_find);
 >  EXPORT_SYMBOL(ip_rt_ioctl);

And then it's used here:

 > +int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr)
 > +{
 > +    struct net_device *dev;
 > +    u32 ip = ((struct sockaddr_in *) addr)->sin_addr.s_addr;
 > +    int ret;
 > +
 > +    dev = ip_dev_find(ip);
 > +    if (!dev)
 > +            return -EADDRNOTAVAIL;
 > +
 > +    ret = copy_addr(dev_addr, dev, NULL);
 > +    dev_put(dev);
 > +    return ret;
 > +}

And also here to find the local device to use when connecting to a
loopback address:

 > +static int addr_resolve_local(struct sockaddr_in *src_in,
 > +                          struct sockaddr_in *dst_in,
 > +                          struct rdma_dev_addr *addr)
 > +{
 > +    struct net_device *dev;
 > +    u32 src_ip = src_in->sin_addr.s_addr;
 > +    u32 dst_ip = dst_in->sin_addr.s_addr;
 > +    int ret;
 > +
 > +    dev = ip_dev_find(dst_ip);
 > +    if (!dev)
 > +            return -EADDRNOTAVAIL;
 > +
 > +    if (!src_ip) {
 > +            src_in->sin_family = dst_in->sin_family;
 > +            src_in->sin_addr.s_addr = dst_ip;
 > +            ret = copy_addr(addr, dev, dev->dev_addr);
 > +    } else {
 > +            ret = rdma_translate_ip((struct sockaddr *)src_in, addr);
 > +            if (!ret)
 > +                    memcpy(addr->dst_dev_addr, dev->dev_addr, MAX_ADDR_LEN);
 > +    }
 > +
 > +    dev_put(dev);
 > +    return ret;
 > +}

I don't really have an opinion one way or another about this usage,
but I think it's a good idea to make sure that this stuff doesn't get
lost in all the other code, since it is (re)exporting a function that
is currently private to networking.

 - R.
_______________________________________________
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to