Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Winkler, Tomas" <tomas.winkler@intel.com>
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Christoph Hellwig" <hch@lst.de>
Subject: RE: [PATCH v1] mei: Don't encourage to use kernel internal types in
 user code
Thread-Topic: [PATCH v1] mei: Don't encourage to use kernel internal types in
 user code
Thread-Index: AQHV7kmoHRGWq8a92EO3ikJkF4xQsagyWSTQgAL/iQCAAECokA==
Date:   Mon, 2 Mar 2020 18:05:38 +0000
Message-ID: <c42fc7597d7c4d0a9867c41a94b0844b@intel.com>
References: <20200228151328.45062-1-andriy.shevchenko@linux.intel.com>
 <3bb5abe91919458aa6166eb60d9451ff@intel.com>
 <20200302155818.GG1224808@smile.fi.intel.com>
In-Reply-To: <20200302155818.GG1224808@smile.fi.intel.com>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.2.0.6
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> 
> +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