From mboxrd@z Thu Jan 1 00:00:00 1970 From: Or Gerlitz Subject: Re: [PATCH V4 for-next 2/4] IB/core: Infra-structure to support verbs extensions through uverbs Date: Wed, 14 Aug 2013 13:04:56 +0300 Message-ID: <520B5648.3050000@mellanox.com> References: <1375873322-19384-1-git-send-email-ogerlitz@mellanox.com> <1375873322-19384-3-git-send-email-ogerlitz@mellanox.com> <520B4897.2010608@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <520B4897.2010608-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Roland Dreier Cc: "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Hadar Hen Zion , matanb , Shawn Bohrer , Sean Hefty , Igor Ivanov List-Id: linux-rdma@vger.kernel.org On 14/08/2013 12:06, Or Gerlitz wrote: > On 13/08/2013 22:18, Roland Dreier wrote: >>> >+struct ib_uverbs_cmd_hdr_ex { >>> >+ __u32 command; >>> >+ __u16 in_words; >>> >+ __u16 out_words; >>> >+ __u16 provider_in_words; >>> >+ __u16 provider_out_words; >>> >+ __u32 cmd_hdr_reserved; >>> >+}; >>> >+ >> If I understand the vague explanations and the analogy to the >> presentation about userspace, then cmd_hdr_reserved is supposed to be >> used as a mask field. Should a kernel that doesn't understand any >> mask components make sure that this reserved field is 0, and return an >> error if it isn't? I don't see any code to do that, and it seems to >> risk new userspace silently getting wrong answers on an old kernel. >> >> Is there any reason not to name it as a mask field from the start? > > > NO. > > The last field in the extended uverbs command header isn't for > extending the command for which this instance serves as the header. Its role is to make sure we are aligned to intergral multiplicative of 64bit as the non extended header. -- 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