> -----Original Message----- > From: Jason Gunthorpe [mailto:jgg@xxxxxxxxxxxx] > Sent: Monday, March 12, 2018 3:22 PM > To: Ruhl, Michael J <michael.j.ruhl@xxxxxxxxx> > Cc: Leon Romanovsky <leon@xxxxxxxxxx>; Doug Ledford > <dledford@xxxxxxxxxx>; Leon Romanovsky <leonro@xxxxxxxxxxxx>; > RDMA mailing list <linux-rdma@xxxxxxxxxxxxxxx>; Aviad Yehezkel > <aviadye@xxxxxxxxxxxx>; Boris Pismenny <borisp@xxxxxxxxxxxx>; Matan > Barak <matanb@xxxxxxxxxxxx>; Yishai Hadas <yishaih@xxxxxxxxxxxx> > Subject: Re: [PATCH rdma-next 06/12] IB/uverbs: Add enum attribute type to > ioctl() interface > > On Mon, Mar 12, 2018 at 07:09:05PM +0000, Ruhl, Michael J wrote: > > Is there are reason that you are adding a new data structure instead of > doing > > this: > > > > - __aligned_u64 data; /* ptr to command, inline data or idr/fd */ > > + __aligned_u64 data; /* ptr to command, inline data, idr/fd, or > enum */ > > > > ? > > > > I see that the enum fits in the __16 reserved space, but you could > "unionize" the > > __u64 data, and use it consistently just as you use it or all the other data > types > > (and match how the attribute data structures are being used/optimized) > > The new type passes both a enum tag and a PTR_IN, they can't be > combined. Ahh, I missed that point. > The use is in places where you have a blob of data that would be oqaue > to the core code (say an address in opa/iwarp/ib/etc) then it comes > along with the 'type' of that opaque data at the same time, then the > ioctl layer can check and validate. Thanks for the explanation. Mike > Sort of similar to how sockaddr works, execpt the type is kept out of > band. > > 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
