> -----Original Message----- > From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, May 27, 2015 20:29 > To: Winkler, Tomas > Cc: arnd@xxxxxxxx; Stephen Rothwell; linux-api@xxxxxxxxxxxxxxx > Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw > arrays > > On Wed, May 27, 2015 at 05:24:01PM +0000, Winkler, Tomas wrote: > > > > > > > > On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote: > > > > In order for mei client devices to use device id based on uuid we > > > > have to use common types between user space (file2alias.c). > > > > Similarly to vmbus, mei uses raw 16 byte array for that. > > > > To leverage on existing infrastructure around uuid_le type > > > > defined in uuid.h we add helper macros to handle conversions between > > > > raw 16 byte array and uuid_{le,be} types. > > > > > > You aren't adding a helper macro, you are just redefining the existing > > > macros using a different one. > > > > Not exactly I'm using both the one I've added for device ids and the old one for > all the other flows. > > > > But I can't see why this is needed, what > > > does this solve that vmbus and other uses of the existing macros don't > > > need? In other words, what makes mei so special that it needs a "lower" > > > level macro than every other subsystem? > > > > It's not special there is actually a lot of code duplication around uuid handling > > every subsystem is using their own macros but it can be consolidated around > uuid.h > > > > So vmbus can use that > > Instead of > > /* > > * Network GUID > > * {f8615163-df3e-46c5-913f-f2d2f965ed0e} > > */ > > #define HV_NIC_GUID \ > > .guid = { \ > > 0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46, \ > > 0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e \ > > } > > > > The can use the new macro to make it more readable, something in spirit of: > > > > #define HV_NIC_GUID __UUID_LE(f8615163-df3e-46c5-913f-f2d2f965ed0e) > > Why the "__" usage here? That signifies a "private" namespace, why add > that to the user visible header files? I take any other suggestion for macro names. Not sure how I would reuse the macros if I don't export them both, second this can be used also by user space. > > And are you going to send patches for vmbus and other drivers to fix > everything up to use these new macros? Someone has to... Can be done but I cannot test their code and now I'm busy with splitting the big bus patch :) Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
