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: > > 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. > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
