Re: 2.6.16-rc6-mm2: new RDMA CM EXPORT_SYMBOL's

[Matthew Frost <artusemrys@sbcglobal.net>]

--- Andrew Morton <akpm@osdl.org> wrote:

> "Sean Hefty" <sean.hefty@intel.com> wrote:
> >
> > >I'm not exactly happy that this tree adds tons of RDMA CM
> > >EXPORT_SYMBOL's that are neither currently used nor _GPL.
> > 
> > The symbols are used by the kernel component that provides userspace
> support.
> > 
> 
> There's brevity and then there is obscurity.
> 

To the point.  I, insightful betimes, but a non-user of the technology,
can grep TFM's and find out what the names could mean, but we're left
guessing at what some of these *do*.  Translating names falls into the
"any idiot can" category of data mining, but if you code for them, we can
see context.  If you named them more transparently, we might even use
them right.  Maybe just comment well?

RDMA
+EXPORT_SYMBOL(rdma_wq); Work Queue (do what to it?)
+EXPORT_SYMBOL(rdma_translate_ip); Translate IP Address
+EXPORT_SYMBOL(rdma_resolve_ip); Resolve IP Address
+EXPORT_SYMBOL(rdma_addr_cancel); Address Cancel (memory?)
+EXPORT_SYMBOL(rdma_create_id); Create (?) ID
+EXPORT_SYMBOL(rdma_create_qp); Create Queue Pair (WQ,CQ)
+EXPORT_SYMBOL(rdma_destroy_qp); Destroy Queue Pair (WQ,CQ)
+EXPORT_SYMBOL(rdma_init_qp_attr); Set Initial Queue Pair Attributes (?)
+EXPORT_SYMBOL(rdma_destroy_id); Destroy (?) ID
+EXPORT_SYMBOL(rdma_listen); Listen (to ... socket, port, pipe, what?)
+EXPORT_SYMBOL(rdma_resolve_route); Resolve Route (datagram path?)
+EXPORT_SYMBOL(rdma_resolve_addr); Resolve Address (memory?)
+EXPORT_SYMBOL(rdma_bind_addr); Bind Address (memory?)
+EXPORT_SYMBOL(rdma_connect); Connect
+EXPORT_SYMBOL(rdma_accept); Accept
+EXPORT_SYMBOL(rdma_reject); Reject
+EXPORT_SYMBOL(rdma_disconnect); Disconnect

Address vs. IP - I know we're talking about a net/dma kluge here, but the
twin usage is bugging me.  I'm intuiting the _addr as memory addresses,
rather than IP addresses, which seem to be _ip, but my poor gray goo
suffers pointer overload.

INFINIBAND
+EXPORT_SYMBOL(ib_get_rmpp_segment); Reliable MultiPacket Protocol
+EXPORT_SYMBOL(ib_copy_qp_attr_to_user); Push Queue Pair Attribute
+EXPORT_SYMBOL(ib_copy_path_rec_to_user); Push Path Record
+EXPORT_SYMBOL(ib_copy_path_rec_from_user); Retrieve Path Record
+EXPORT_SYMBOL(ib_modify_qp_is_ok); Yes, Modify Queue Pair, or "QP is
OK", or "QP was Modified OK"?
+EXPORT_SYMBOL(ip_dev_find); Find IP device (sub(/ip/, "ib")? find the
network interface device?)

> 
> Some or all of those exports have no in-tree users.
> 
> What code will use them?
> 
> Is it planned that this code be merged?

*Can* work that uses them be merged?  Code that requires a non-GPL
export?

> 
> Please explain the thinking behind the choice of a non-GPL export. 
> (Yes, we discussed this when inifiniband was first merged, but it
> doesn't hurt to reiterate).
> 

Color me curious ...
Frosty
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/