On Thu, Mar 29, 2018 at 09:48:08AM -0500, Steve Wise wrote: > > > On 3/28/2018 3:26 PM, Jason Gunthorpe wrote: > > On Wed, Mar 28, 2018 at 07:51:58AM +0300, Leon Romanovsky wrote: > >> On Tue, Mar 27, 2018 at 10:35:27PM -0600, Jason Gunthorpe wrote: > >>> On Tue, Mar 27, 2018 at 09:58:13AM -0500, Steve Wise wrote: > >>> > >>>> Steve's proposed attributes like BLAH_U32, BLAH_X32, and BLAH_D32 > >>>> are efficient because they convey, directly, how the user side > >>>> should display them. Leon prefers a separate string attribute that > >>>> is provided along with the value to convey the display format, and > >>>> the default would be unsigned so the display format attribute could > >>>> be excluded and the user side knows to use "%u". > >>> Signed or not should be part of the attribute type for sure, just for > >>> sanity. We should type check those things.. > >> There is type NLA_S64 especially for this. > >> > >>> That just leaves X or not X, and why does that matter to anyone? > >> As I posted before, I want to reuse those fields for set operations and > >> want to ensure that drivers/core won't need to deal with users who send > >> the same field sometimes with X64 and sometimes with U64 which for the > >> kernel are the same. > > Okay.. Can't you just encode the hex/!hex in the name string somehow? > > Start with ! or something for hex. > > Seems like a big wast to include another attribute just for this. > > Leon? I didn't understand that it was for me. First, we have upto 64K attributes till we will exhaust them, second it is not only hex and not hex, but binary too. Thanks
Attachment:
signature.asc
Description: PGP signature
