Re: [RFC ABI V2 5/8] RDMA/core: Add new ioctl interface

On Thu, Jul 21, 2016 at 01:04:33AM -0700, Christoph Hellwig wrote:

On Wed, Jul 20, 2016 at 11:44:39PM -0600, Jason Gunthorpe wrote:

quoted

How many ioctls have you used that use a complex variable sized struct
as the parameter?

There are a few and they ones I've used are self-describing one way or
another. Perhaps they have an op code or something in the struct, or a
netlink-like format, or *something* but you don't need to know what
the fd is connected to in order to parse the struct. The ioctl # and
the argument should be enough to parse.

In that case they are designed by taste-less fools.  No need to
to spread that BS even further.

Well, what do you suggest then? This sounds like we are back to the
~500 ioctls. Is that OK & better?

This is not a small interface, and when you add in all the
driver-specific stuff there are *alot* of different API
call signatures..

I'm not so sure I want to see MLX5_CREATE_QP, MLX4_CREATE_QP,
QIB_CREATE_QP, etc, etc as ioctl numbers, that seems difficult
to implement the common code for.

quoted

You are really surprised by the rdma_cm architecture??? I know it is
goofy, but we are stuck with it..

Are we?  We'll need to stick to the wire format obviously, but the
software architectures needs to die rather sooner than later.  It's the
worst pile of junk in the RDMA subsystem, and that really means
something.  It's almost impossible to use it correctly due to all the
warts and un- or under-documented assumtions in it's APIs.

I think we are, it is baked into user space ...

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html