Messages in this thread | | | Date | Mon, 13 Dec 2021 22:18:16 +0200 | From | Andy Shevchenko <> | Subject | Re: [PATCH v1 1/1] virt: acrn: Drop internal kernel type from ABI |
| |
On Fri, Oct 01, 2021 at 05:10:10PM +0200, Greg Kroah-Hartman wrote: > On Fri, Oct 01, 2021 at 05:58:49PM +0300, Andy Shevchenko wrote: > > On Fri, Oct 01, 2021 at 04:01:41PM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Oct 01, 2021 at 04:56:44PM +0300, Andy Shevchenko wrote: > > > > guid_t is internal type of the kernel which is mistakenly had been exposed > > > > to the user space. Replace it with raw buffers. > > > > > > Wait, why is it a mistake to expose it to userspace? What does this > > > conflict with? Is it a namespace issue? Or something else? > > > > It is the type which is defined solely for kernel use and what user space > > should do is to use types defined by respective libraries, such as libuuid. > > But that does not work here. We want to expose a common uuid type that > userspace can use in these structures, as well as the kernel. Do you > really want to "open code" arrays all over the place?
It's not used "all over a place", the only code is recently added by this driver.
> > If you read the commit message to the end, you will notice that I have > > mentioned the possible scenario what happened here. They seems misusing > > guid_t as uuid_t, but the latter is not available for the users from > > the kernel headers (and this is good). So this is an exact example why > > guid_t shouldn't be exposed. > > Then we should create a type that we can use here. The kernel can not > use libuuid, so what is wrong with using the kernel variable type > namespace for this? __guid? __uuid?
Why? "All over the place" except this code (okay and one more, i.e. MEI, but this is another story) we use raw arrays in ABI. Why virt out of a sudden need a special _kernel_ type for that? I think the author simply missed this subtle detail that it's not supposed to be outside of the kernel.
-- With Best Regards, Andy Shevchenko
| |