All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: "Will Cohen" <wwcohen@gmail.com>,
	"Philippe Mathieu-Daudé" <philippe.mathieu.daude@gmail.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Fabian Franz" <fabianfranz.oss@gmail.com>,
	"Greg Kurz" <groug@kaod.org>,
	"Keno Fischer" <keno@juliacomputing.com>,
	"Michael Roitzsch" <reactorcontrol@icloud.com>,
	hi@alyssa.is
Subject: Re: [PATCH] 9p: move limits.h include from 9p.c to 9p.h
Date: Thu, 31 Mar 2022 12:20:00 +0200	[thread overview]
Message-ID: <1945982.nC2RM7dPtK@silver> (raw)
In-Reply-To: <CAB26zV0StFAcX3KbwfTpXZxjza8N0gr2S5zMwQEJPCKxBEQ5Sw@mail.gmail.com>

On Mittwoch, 30. März 2022 23:17:02 CEST Will Cohen wrote:
> On Wed, Mar 30, 2022 at 4:24 PM Philippe Mathieu-Daudé <
> 
> philippe.mathieu.daude@gmail.com> wrote:
> > Hi,
> > 
> > On 30/3/22 20:19, Will Cohen wrote:
> > > As noted by https://gitlab.com/qemu-project/qemu/-/issues/950, within
> > > the patch set adding 9p functionality to darwin, the commit
> > > 38d7fd68b0c8775b5253ab84367419621aa032e6 introduced an issue where
> > > limits.h, which defines XATTR_SIZE_MAX, is included in 9p.c, though the
> > > referenced constant is needed in 9p.h. This commit fixes that issue by
> > > moving the include to 9p.h.
> > 
> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/950
> 
> Thanks -- I'll adjust the syntax accordingly in v2.

As you are sending a v2 anyway, then also add please:

Fixes: 38d7fd68b0 ("9p: darwin: Move XATTR_SIZE_MAX->P9_XATTR_SIZE_MAX")

Also note ...

> > > Signed-off-by: Will Cohen <wwcohen@gmail.com>
> > > ---
> > > 
> > >   hw/9pfs/9p.c | 5 -----
> > >   hw/9pfs/9p.h | 5 +++++
> > >   2 files changed, 5 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > > index dcaa602d4c..59c531ed47 100644
> > > --- a/hw/9pfs/9p.c
> > > +++ b/hw/9pfs/9p.c
> > > @@ -33,11 +33,6 @@
> > > 
> > >   #include "migration/blocker.h"
> > >   #include "qemu/xxhash.h"
> > >   #include <math.h>
> > > 
> > > -#ifdef CONFIG_LINUX
> > > -#include <linux/limits.h>
> > > -#else
> > > -#include <limits.h>
> > > -#endif
> > > 
> > >   int open_fd_hw;
> > >   int total_open_fd;
> > > 
> > > diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
> > > index af2635fae9..0ce4da375c 100644
> > > --- a/hw/9pfs/9p.h
> > > +++ b/hw/9pfs/9p.h
> > > @@ -9,6 +9,11 @@
> > > 
> > >   #include "qemu/thread.h"
> > >   #include "qemu/coroutine.h"
> > >   #include "qemu/qht.h"
> > > 
> > > +#ifdef CONFIG_LINUX
> > > +#include <linux/limits.h>
> > > +#else
> > > +#include <limits.h>
> > > +#endif

... it is usually better to include system headers before project headers.

> > 
> > Except XATTR_SIZE_MAX, I don't see anything in 9p.h which
> > requires <limits.h>.
> > 
> > $ git grep P9_XATTR_SIZE_MAX
> > hw/9pfs/9p.c:3960:    if (size > P9_XATTR_SIZE_MAX) {
> > hw/9pfs/9p.h:484:#define P9_XATTR_SIZE_MAX XATTR_SIZE_MAX
> > hw/9pfs/9p.h:495:#define P9_XATTR_SIZE_MAX 65536
> > hw/9pfs/9p.h:497:#error Missing definition for P9_XATTR_SIZE_MAX for
> > this host system
> > 
> > Only 9p.c requires this definition, what about moving the
> > offending code to the .c?
> 
> That works as well. I suppose I was just trying to keep it conceptually
> cleaner with the constants in the .h, but on second thought I agree keeping
> it more efficiently contained in the .c is a better move. Will resubmit
> with that change as v2.
> 
> > Regards,
> > 
> > Phil.




  reply	other threads:[~2022-03-31 10:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 18:19 [PATCH] 9p: move limits.h include from 9p.c to 9p.h Will Cohen
2022-03-30 20:23 ` Philippe Mathieu-Daudé
2022-03-30 21:17   ` Will Cohen
2022-03-31 10:20     ` Christian Schoenebeck [this message]
2022-03-30 21:31 ` Peter Maydell
2022-03-30 21:55   ` Will Cohen
2022-03-31  8:03     ` Peter Maydell
2022-03-31 11:07       ` Christian Schoenebeck
2022-03-31 13:19         ` Will Cohen
2022-03-31 15:34           ` Christian Schoenebeck
2022-03-31 17:57             ` Will Cohen

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=1945982.nC2RM7dPtK@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=fabianfranz.oss@gmail.com \
    --cc=groug@kaod.org \
    --cc=hi@alyssa.is \
    --cc=keno@juliacomputing.com \
    --cc=philippe.mathieu.daude@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=reactorcontrol@icloud.com \
    --cc=thuth@redhat.com \
    --cc=wwcohen@gmail.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 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.