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?
And are you going to send patches for vmbus and other drivers to fix
everything up to use these new macros? Someone has to...
thanks,
greg k-h
--
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
