From: "Michael S. Tsirkin" <mst@redhat.com>
To: Shunsuke Mie <mie@igel.co.jp>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
virtualization@lists.linux-foundation.org,
"Eugenio Pérez" <eperezma@redhat.com>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH v2 2/2] tools/virtio: fix build caused by virtio_ring changes
Date: Tue, 11 Apr 2023 02:37:54 -0400 [thread overview]
Message-ID: <20230411023026-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <de392fbd-3ffd-466d-cc7f-32f55c03227f@igel.co.jp>
On Tue, Apr 11, 2023 at 12:25:39PM +0900, Shunsuke Mie wrote:
>
> On 2023/04/11 4:44, Michael S. Tsirkin wrote:
> > On Mon, Apr 10, 2023 at 08:40:34PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Apr 10, 2023 at 08:00:33AM -0400, Michael S. Tsirkin wrote:
> > > > On Mon, Apr 10, 2023 at 08:28:45PM +0900, Shunsuke Mie wrote:
> > > > > Fix the build dependency for virtio_test. The virtio_ring that is used from
> > > > > the test requires container_of_const(). Change to use container_of.h kernel
> > > > > header directly and adapt related codes.
> > > > >
> > > > > Signed-off-by: Shunsuke Mie <mie@igel.co.jp>
> > > > This is only for next right? That's where container_of_const
> > > > things are I think ...
> > > container_of_const() is in 6.2.
> >
> > Absolutely but the patch switching virtio to that is not there.
> >
> >
> > > > > ---
> > > > > tools/include/linux/types.h | 1 -
> > > > > tools/virtio/linux/compiler.h | 2 ++
> > > > > tools/virtio/linux/kernel.h | 5 +----
> > > > > tools/virtio/linux/module.h | 1 -
> > > > > tools/virtio/linux/uaccess.h | 11 ++---------
> > > > > 5 files changed, 5 insertions(+), 15 deletions(-)
> > > > >
> > > > > diff --git a/tools/include/linux/types.h b/tools/include/linux/types.h
> > > > > index 051fdeaf2670..f1896b70a8e5 100644
> > > > > --- a/tools/include/linux/types.h
> > > > > +++ b/tools/include/linux/types.h
> > > > > @@ -49,7 +49,6 @@ typedef __s8 s8;
> > > > > #endif
> > > > > #define __force
> > > > > -#define __user
> > > Why is this needed?
> > >
> > > > > #define __must_check
> > > > > #define __cold
> > > > > diff --git a/tools/virtio/linux/compiler.h b/tools/virtio/linux/compiler.h
> > > > > index 2c51bccb97bb..1f3a15b954b9 100644
> > > > > --- a/tools/virtio/linux/compiler.h
> > > > > +++ b/tools/virtio/linux/compiler.h
> > > > > @@ -2,6 +2,8 @@
> > > > > #ifndef LINUX_COMPILER_H
> > > > > #define LINUX_COMPILER_H
> > > > > +#include "../../../include/linux/compiler_types.h"
> > > While I understand your need to not want to duplicate code, what in the
> > > world is this doing? Why not use the in-kernel compiler.h instead? Why
> > > are you copying loads of .h files into tools/virtio/? What is this for
> > > and why not just use the real files so you don't have to even attempt to
> > > try to keep things in sync (hint, they will always be out of sync.)
> > Because it's doing a very weird hack: building some kernel
> > code into a userspace binary, used for just for testing.
> > This is all not part of kernel build intentionally, no
> > one is supposed to use this binary in production, but
> > it was helpful in finding bugs in virtio core in the past
> > so I keep it around.
> Would it be possible to switch to in-kernel tests, such as KUnit? If it's
> possible, we could use the kernel headers and implementations as they are,
> and we could address the concerns that Greg raised I think.
>
>
> Best regards,
>
> Shunsuke
I think your patch is fine as is. Using kunit is certainly possible,
but won't be a small project. tools/virtio was always a quick
hack to help experiment quickly, so I'm not worried by it being
broken often - whoever wants to play with it next, fixes it up.
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Shunsuke Mie <mie@igel.co.jp>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jason Wang" <jasowang@redhat.com>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v2 2/2] tools/virtio: fix build caused by virtio_ring changes
Date: Tue, 11 Apr 2023 02:37:54 -0400 [thread overview]
Message-ID: <20230411023026-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <de392fbd-3ffd-466d-cc7f-32f55c03227f@igel.co.jp>
On Tue, Apr 11, 2023 at 12:25:39PM +0900, Shunsuke Mie wrote:
>
> On 2023/04/11 4:44, Michael S. Tsirkin wrote:
> > On Mon, Apr 10, 2023 at 08:40:34PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Apr 10, 2023 at 08:00:33AM -0400, Michael S. Tsirkin wrote:
> > > > On Mon, Apr 10, 2023 at 08:28:45PM +0900, Shunsuke Mie wrote:
> > > > > Fix the build dependency for virtio_test. The virtio_ring that is used from
> > > > > the test requires container_of_const(). Change to use container_of.h kernel
> > > > > header directly and adapt related codes.
> > > > >
> > > > > Signed-off-by: Shunsuke Mie <mie@igel.co.jp>
> > > > This is only for next right? That's where container_of_const
> > > > things are I think ...
> > > container_of_const() is in 6.2.
> >
> > Absolutely but the patch switching virtio to that is not there.
> >
> >
> > > > > ---
> > > > > tools/include/linux/types.h | 1 -
> > > > > tools/virtio/linux/compiler.h | 2 ++
> > > > > tools/virtio/linux/kernel.h | 5 +----
> > > > > tools/virtio/linux/module.h | 1 -
> > > > > tools/virtio/linux/uaccess.h | 11 ++---------
> > > > > 5 files changed, 5 insertions(+), 15 deletions(-)
> > > > >
> > > > > diff --git a/tools/include/linux/types.h b/tools/include/linux/types.h
> > > > > index 051fdeaf2670..f1896b70a8e5 100644
> > > > > --- a/tools/include/linux/types.h
> > > > > +++ b/tools/include/linux/types.h
> > > > > @@ -49,7 +49,6 @@ typedef __s8 s8;
> > > > > #endif
> > > > > #define __force
> > > > > -#define __user
> > > Why is this needed?
> > >
> > > > > #define __must_check
> > > > > #define __cold
> > > > > diff --git a/tools/virtio/linux/compiler.h b/tools/virtio/linux/compiler.h
> > > > > index 2c51bccb97bb..1f3a15b954b9 100644
> > > > > --- a/tools/virtio/linux/compiler.h
> > > > > +++ b/tools/virtio/linux/compiler.h
> > > > > @@ -2,6 +2,8 @@
> > > > > #ifndef LINUX_COMPILER_H
> > > > > #define LINUX_COMPILER_H
> > > > > +#include "../../../include/linux/compiler_types.h"
> > > While I understand your need to not want to duplicate code, what in the
> > > world is this doing? Why not use the in-kernel compiler.h instead? Why
> > > are you copying loads of .h files into tools/virtio/? What is this for
> > > and why not just use the real files so you don't have to even attempt to
> > > try to keep things in sync (hint, they will always be out of sync.)
> > Because it's doing a very weird hack: building some kernel
> > code into a userspace binary, used for just for testing.
> > This is all not part of kernel build intentionally, no
> > one is supposed to use this binary in production, but
> > it was helpful in finding bugs in virtio core in the past
> > so I keep it around.
> Would it be possible to switch to in-kernel tests, such as KUnit? If it's
> possible, we could use the kernel headers and implementations as they are,
> and we could address the concerns that Greg raised I think.
>
>
> Best regards,
>
> Shunsuke
I think your patch is fine as is. Using kunit is certainly possible,
but won't be a small project. tools/virtio was always a quick
hack to help experiment quickly, so I'm not worried by it being
broken often - whoever wants to play with it next, fixes it up.
--
MST
next prev parent reply other threads:[~2023-04-11 6:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 11:28 [PATCH v2 1/2] virtio_ring: add a struce device forward declaration Shunsuke Mie
2023-04-10 11:28 ` Shunsuke Mie
2023-04-10 11:28 ` [PATCH v2 2/2] tools/virtio: fix build caused by virtio_ring changes Shunsuke Mie
2023-04-10 11:28 ` Shunsuke Mie
2023-04-10 12:00 ` Michael S. Tsirkin
2023-04-10 12:00 ` Michael S. Tsirkin
2023-04-10 18:40 ` Greg Kroah-Hartman
2023-04-10 18:40 ` Greg Kroah-Hartman
2023-04-10 19:44 ` Michael S. Tsirkin
2023-04-10 19:44 ` Michael S. Tsirkin
2023-04-11 3:25 ` Shunsuke Mie
2023-04-11 3:25 ` Shunsuke Mie
2023-04-11 6:37 ` Michael S. Tsirkin [this message]
2023-04-11 6:37 ` Michael S. Tsirkin
2023-04-11 3:17 ` Shunsuke Mie
2023-04-11 3:17 ` Shunsuke Mie
2023-04-10 11:49 ` [PATCH v2 1/2] virtio_ring: add a struce device forward declaration Michael S. Tsirkin
2023-04-10 11:49 ` Michael S. Tsirkin
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=20230411023026-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=eperezma@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mie@igel.co.jp \
--cc=rafael@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.