All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Jeff Layton <jlayton@kernel.org>, Christoph Hellwig <hch@lst.de>,
	Guo Ren <guoren@kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
Date: Wed, 12 Jan 2022 17:09:35 +0100	[thread overview]
Message-ID: <20220112160935.GA3684@lst.de> (raw)
In-Reply-To: <CAK8P3a3FgHQ+w+Sj00yOERRLWfVhx7NYsGJ1NBAXQ0=is3G=Kg@mail.gmail.com>

On Wed, Jan 12, 2022 at 01:08:24PM +0100, Arnd Bergmann wrote:
> > I don't have a strong opinion here. If we were taking symbols away that
> > were previously visible to userland it would be one thing, but since
> > we're just adding symbols that may not have been there before, this
> > seems less likely to break anything.
> 
> Changing
> 
> #ifndef CONFIG_64BIT
> 
> to
> 
> #if __BITS_PER_LONG==32 || defined(__KERNEL__),
> 
> would take symbols away, since the CONFIG_64BIT macro is never
> set in user space.

Yes.

> > I probably lean toward Christoph's original solution instead of keeping
> > the conditional definitions. It's hard to imagine there are many
> > programs that care whether these other symbols are defined or not.
> >
> > You can add this to the original patch:
> >
> > Acked-by: Jeff Layton <jlayton@kernel.org>
> 
> Sounds good, thanks

So should we go ahead with the series as-is?  Or respin it?  Or add
the above change ontop?

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Jeff Layton <jlayton@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Guo Ren <guoren@kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Christoph Hellwig <hch@lst.de>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
Date: Wed, 12 Jan 2022 17:09:35 +0100	[thread overview]
Message-ID: <20220112160935.GA3684@lst.de> (raw)
In-Reply-To: <CAK8P3a3FgHQ+w+Sj00yOERRLWfVhx7NYsGJ1NBAXQ0=is3G=Kg@mail.gmail.com>

On Wed, Jan 12, 2022 at 01:08:24PM +0100, Arnd Bergmann wrote:
> > I don't have a strong opinion here. If we were taking symbols away that
> > were previously visible to userland it would be one thing, but since
> > we're just adding symbols that may not have been there before, this
> > seems less likely to break anything.
> 
> Changing
> 
> #ifndef CONFIG_64BIT
> 
> to
> 
> #if __BITS_PER_LONG==32 || defined(__KERNEL__),
> 
> would take symbols away, since the CONFIG_64BIT macro is never
> set in user space.

Yes.

> > I probably lean toward Christoph's original solution instead of keeping
> > the conditional definitions. It's hard to imagine there are many
> > programs that care whether these other symbols are defined or not.
> >
> > You can add this to the original patch:
> >
> > Acked-by: Jeff Layton <jlayton@kernel.org>
> 
> Sounds good, thanks

So should we go ahead with the series as-is?  Or respin it?  Or add
the above change ontop?

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Jeff Layton <jlayton@kernel.org>, Christoph Hellwig <hch@lst.de>,
	Guo Ren <guoren@kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
Date: Wed, 12 Jan 2022 17:09:35 +0100	[thread overview]
Message-ID: <20220112160935.GA3684@lst.de> (raw)
In-Reply-To: <CAK8P3a3FgHQ+w+Sj00yOERRLWfVhx7NYsGJ1NBAXQ0=is3G=Kg@mail.gmail.com>

On Wed, Jan 12, 2022 at 01:08:24PM +0100, Arnd Bergmann wrote:
> > I don't have a strong opinion here. If we were taking symbols away that
> > were previously visible to userland it would be one thing, but since
> > we're just adding symbols that may not have been there before, this
> > seems less likely to break anything.
> 
> Changing
> 
> #ifndef CONFIG_64BIT
> 
> to
> 
> #if __BITS_PER_LONG==32 || defined(__KERNEL__),
> 
> would take symbols away, since the CONFIG_64BIT macro is never
> set in user space.

Yes.

> > I probably lean toward Christoph's original solution instead of keeping
> > the conditional definitions. It's hard to imagine there are many
> > programs that care whether these other symbols are defined or not.
> >
> > You can add this to the original patch:
> >
> > Acked-by: Jeff Layton <jlayton@kernel.org>
> 
> Sounds good, thanks

So should we go ahead with the series as-is?  Or respin it?  Or add
the above change ontop?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-12 16:09 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11  8:35 consolidate the compat fcntl definitions Christoph Hellwig
2022-01-11  8:35 ` Christoph Hellwig
2022-01-11  8:35 ` Christoph Hellwig
2022-01-11  8:35 ` [PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64 define Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35 ` [PATCH 2/5] uapi: simplify __ARCH_FLOCK{,64}_PAD a little Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35 ` [PATCH 3/5] uapi: merge the 32-bit mips struct flock into the generic one Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35 ` [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11 15:33   ` Arnd Bergmann
2022-01-11 15:33     ` Arnd Bergmann
2022-01-11 15:33     ` Arnd Bergmann
2022-01-12  2:08     ` Guo Ren
2022-01-12  2:08       ` Guo Ren
2022-01-12  2:08       ` Guo Ren
2022-01-12  7:56     ` Christoph Hellwig
2022-01-12  7:56       ` Christoph Hellwig
2022-01-12  7:56       ` Christoph Hellwig
2022-01-12  8:28       ` Arnd Bergmann
2022-01-12  8:28         ` Arnd Bergmann
2022-01-12  8:28         ` Arnd Bergmann
2022-01-12 11:15         ` Jeff Layton
2022-01-12 11:15           ` Jeff Layton
2022-01-12 11:15           ` Jeff Layton
2022-01-12 12:08           ` Arnd Bergmann
2022-01-12 12:08             ` Arnd Bergmann
2022-01-12 12:08             ` Arnd Bergmann
2022-01-12 16:09             ` Christoph Hellwig [this message]
2022-01-12 16:09               ` Christoph Hellwig
2022-01-12 16:09               ` Christoph Hellwig
2022-01-11  8:35 ` [PATCH 5/5] compat: consolidate the compat_flock{,64} definition Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  9:52   ` David Laight
2022-01-11  9:52     ` David Laight
2022-01-11  9:52     ` David Laight
2022-01-11 15:46 ` consolidate the compat fcntl definitions Arnd Bergmann
2022-01-11 15:46   ` Arnd Bergmann
2022-01-11 15:46   ` Arnd Bergmann
2022-01-12  9:56 ` Sergey Shtylyov
2022-01-12  9:56   ` Sergey Shtylyov
2022-01-12  9:56   ` Sergey Shtylyov
  -- strict thread matches above, loose matches on Subject: below --
2022-01-31  6:49 consolidate the compat fcntl definitions v2 Christoph Hellwig
2022-01-31  6:49 ` [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h Christoph Hellwig
2022-01-31  6:49   ` Christoph Hellwig
2022-01-31  6:49   ` Christoph Hellwig
2022-01-31 13:38   ` Guo Ren
2022-01-31 13:38     ` Guo Ren
2022-01-31 13:38     ` Guo Ren
2022-02-01  3:02   ` Guo Ren
2022-02-01  3:02     ` Guo Ren
2022-02-01  3:02     ` Guo Ren
2022-02-01  3:07     ` Guo Ren
2022-02-01  3:07       ` Guo Ren
2022-02-01  3:07       ` Guo Ren
2021-04-12  8:55 consolidate the flock uapi definitions Christoph Hellwig
2021-04-12  8:55 ` [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h Christoph Hellwig
2021-04-12  8:55   ` Christoph Hellwig
2021-04-12  8:55   ` Christoph Hellwig
2021-04-13 15:43   ` Helge Deller
2021-04-13 15:46     ` Christoph Hellwig
2021-04-13 15:58       ` Helge Deller

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=20220112160935.GA3684@lst.de \
    --to=hch@lst.de \
    --cc=arnd@arndb.de \
    --cc=bfields@fieldses.org \
    --cc=guoren@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=x86@kernel.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.