RE: [PATCH v1] mei: Don't encourage to use kernel internal types in user code

["Winkler, Tomas" <tomas.winkler@intel.com>]

> 
> +Cc: Christoph.
> 
> On Sat, Feb 29, 2020 at 04:28:11PM +0000, Winkler, Tomas wrote:
> > > uuid_le is internal kernel type which shall not be exposed to the
> > > user in the first place.
> > Why, these types are exported via include/uapi/linux/uuid.h
> 
> Which is wrong from the day 1.
I'm not sure why, this is API between kernel and the user space. 

> The uuid_t type is being provided by libuuid in the user space, there is no
> (more) kernel exported equivalent. Same should be done to the uuid_le.

There are many uuid libraries, which  is the one that provides the uuid type
between kernel and the user space? 

> 
> We already discussed this couple of years ago.
I do not recall be part of this conversation, please share the link. 

> 
> > In order to mitigate the (wrong) distribution of the use of that type,
> > > switch MEI AMT sample to plain unsigned char array.
> >
> > There was a change to guid_t from uuild_le, anyhow there is much more
> > code  except this sample that uses those types.
> 
> I guess you misunderstood the point. The types are for kernel use and keeping
> them exported in a condition like it's now (quoter baked due to drop of uuid_be
> part completely and uuid_le partially) is wrong.
Is wrong how... ?  What is broken in the concept ? Please give me an example of what is going to wrong, here. 
Just saying that something is wrong is not convincing. 

> There is *no* ABI change. And basically libuuid or another one should provide
> type and infrastructure for this.
But API is already out there, do you plan to remove it? 
  
> > Nack so far.
> 
> If you would like to bear the legacy type, why not to move this UUID UAPI parts
> directly to MEI?
I can but do you know all the software that includes <linux/uuid.h> ?
Thanks
Tomas