On Wed, Jan 15, 2014 at 11:02:55AM +0100, Yann Droneaud wrote: > > I'd like to have your opinion on this change. > > I'm going to patch every call to ib_copy_from_udata() to follow my > proposed scheme (eg. returned error code from ib_copy_from_udata() > instead of hard coded error value). > Yes, makes sense to me.
> > Is libmlx5/libibverbs the ABI ? > > Unfortunately, anybody is allowed to access the kernel uverbs API > directly, so we must take care of the kernel ABI, just in case. > I am not sure I understand the question but libibverbs to libmlx5 relation is somehow like the relationship between ib_core and mlx5_ib. e.g. libibverbs sets the API and libmlx5 implements it. > > For code not yet part of a released kernel version, we can fix that. > But for all other, it would require proper checking/thinking before > rejecting reserved field not set to 0 since it might theoterically break > existing userspace program: it will be a departure from previous ABI. > Yes, this needs to be done carefully for each driver. We need to check if either libibverbs or any other provider library clears the struct before sending. If this is the case then it should be safe to fix the kernel part. > > I would found more readable to have the two locks held next each other. > YMMV. > I am not following you here. Please be more specific. > > > But it's the size of struct mlx5_modify_cq_mbox_in, not the number of > 'cqe' to resize the cq to. > Oh I see. Well, I don't think it will ever matter that I using int. I use it in other places too. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
