From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Reinette Chatre <reinette.chatre@intel.com>,
Shuo Liu <shuo.a.liu@intel.com>, Zhi Wang <zhi.a.wang@intel.com>,
linux-kernel@vger.kernel.org, Fei Li <fei1.li@intel.com>
Subject: Re: [PATCH v1 1/1] virt: acrn: Drop internal kernel type from ABI
Date: Mon, 13 Dec 2021 22:18:16 +0200 [thread overview]
Message-ID: <YbeqiHg3LxIFCaAU@smile.fi.intel.com> (raw)
In-Reply-To: <YVck0pu9wkUM++Rf@kroah.com>
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
prev parent reply other threads:[~2021-12-13 20:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-01 13:56 [PATCH v1 1/1] virt: acrn: Drop internal kernel type from ABI Andy Shevchenko
2021-10-01 14:01 ` Greg Kroah-Hartman
2021-10-01 14:58 ` Andy Shevchenko
2021-10-01 15:10 ` Greg Kroah-Hartman
2021-12-13 20:18 ` Andy Shevchenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YbeqiHg3LxIFCaAU@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=fei1.li@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=shuo.a.liu@intel.com \
--cc=zhi.a.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox