On Tue, Feb 1, 2022 at 11:02 AM Guo Ren wrote:
>
> On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig wrote:
> >
> > The F_GETLK64/F_SETLK64/F_SETLKW64 fcntl opcodes are only implemented
> > for the 32-bit syscall APIs, but are also needed for compat handling
> > on 64-bit kernels.
> >
> > Consoli
On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig wrote:
>
> The F_GETLK64/F_SETLK64/F_SETLKW64 fcntl opcodes are only implemented
> for the 32-bit syscall APIs, but are also needed for compat handling
> on 64-bit kernels.
>
> Consolidate them in unistd.h instead of definining the internal compat
Acked-by: Guo Ren
On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig wrote:
>
> The F_GETLK64/F_SETLK64/F_SETLKW64 fcntl opcodes are only implemented
> for the 32-bit syscall APIs, but are also needed for compat handling
> on 64-bit kernels.
>
> Consolidate them in unistd.h instead of definining
The F_GETLK64/F_SETLK64/F_SETLKW64 fcntl opcodes are only implemented
for the 32-bit syscall APIs, but are also needed for compat handling
on 64-bit kernels.
Consolidate them in unistd.h instead of definining the internal compat
definitions in compat.h, which is rather errror prone (e.g. parisc
ge
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
On Wed, Jan 12, 2022 at 12:15 PM Jeff Layton wrote:
> On Wed, 2022-01-12 at 09:28 +0100, Arnd Bergmann wrote:
> > On Wed, Jan 12, 2022 at 8:56 AM Christoph Hellwig wrote:
> >
> > Exactly, that is the tradeoff, which is why I'd like the flock maintainers
> > to say which way they prefer. We can ei
On Wed, 2022-01-12 at 09:28 +0100, Arnd Bergmann wrote:
> On Wed, Jan 12, 2022 at 8:56 AM Christoph Hellwig wrote:
> >
> > On Tue, Jan 11, 2022 at 04:33:30PM +0100, Arnd Bergmann wrote:
> > > This is a very subtle change to the exported UAPI header contents:
> > > On 64-bit architectures, the thr
On Wed, Jan 12, 2022 at 8:56 AM Christoph Hellwig wrote:
>
> On Tue, Jan 11, 2022 at 04:33:30PM +0100, Arnd Bergmann wrote:
> > This is a very subtle change to the exported UAPI header contents:
> > On 64-bit architectures, the three unusable numbers are now always
> > shown, rather than depending
On Tue, Jan 11, 2022 at 04:33:30PM +0100, Arnd Bergmann wrote:
> This is a very subtle change to the exported UAPI header contents:
> On 64-bit architectures, the three unusable numbers are now always
> shown, rather than depending on a user-controlled symbol.
Well, the change is bigger and less s
On Tue, Jan 11, 2022 at 11:33 PM Arnd Bergmann wrote:
>
> On Tue, Jan 11, 2022 at 9:35 AM Christoph Hellwig wrote:
> >
> > The fcntl F_GETLK64/F_SETLK64/F_SETLKW64 are only implemented for the
> > 32-bit syscall APIs, but we also need them for compat handling on 64-bit
> > builds. Redefining the
On Tue, Jan 11, 2022 at 9:35 AM Christoph Hellwig wrote:
>
> The fcntl F_GETLK64/F_SETLK64/F_SETLKW64 are only implemented for the
> 32-bit syscall APIs, but we also need them for compat handling on 64-bit
> builds. Redefining them is error prone (as shown by the example that
> parisc gets it wro
The fcntl F_GETLK64/F_SETLK64/F_SETLKW64 are only implemented for the
32-bit syscall APIs, but we also need them for compat handling on 64-bit
builds. Redefining them is error prone (as shown by the example that
parisc gets it wrong currently), so we should use the same defines for
both case. In
The F_GETLK64/F_SETLK64/F_SETLKW64 commands are only implemented for
32-bit syscall APIs, but we also need them for compat handling on 64-bit
kernels.
Given that redefining them is rather error prone, as shown by parisc
getting the opcodes wrong currently, just use the existing definitions
for the
13 matches
Mail list logo
