Messages in this thread | | | From | "Winkler, Tomas" <> | Subject | RE: [PATCH v1] mei: Don't encourage to use kernel internal types in user code | Date | Mon, 2 Mar 2020 18:05:38 +0000 |
| |
> > +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
| |