mbox series

[0/2] openat2: minor uapi cleanups

Message ID 20191219105533.12508-1-cyphar@cyphar.com (mailing list archive)
Headers show
Series openat2: minor uapi cleanups | expand

Message

Aleksa Sarai Dec. 19, 2019, 10:55 a.m. UTC
While openat2(2) is still not yet in Linus's tree, we can take this
opportunity to iron out some small warts that weren't noticed earlier:

  * A fix was suggested by Florian Weimer, to separate the openat2
    definitions so glibc can use the header directly. I've put the
    maintainership under VFS but let me know if you'd prefer it belong
    ot the fcntl folks.

  * Having heterogenous field sizes in an extensible struct results in
    "padding hole" problems when adding new fields (in addition the
    correct error to use for non-zero padding isn't entirely clear ).
    The simplest solution is to just copy clone(3)'s model -- always use
    u64s. It will waste a little more space in the struct, but it
    removes a possible future headache.

Aleksa Sarai (2):
  uapi: split openat2(2) definitions from fcntl.h
  openat2: drop open_how->__padding field

 MAINTAINERS                                   |  1 +
 fs/open.c                                     |  2 -
 include/uapi/linux/fcntl.h                    | 37 +----------------
 include/uapi/linux/openat2.h                  | 40 +++++++++++++++++++
 tools/testing/selftests/openat2/helpers.h     |  3 +-
 .../testing/selftests/openat2/openat2_test.c  | 24 ++++-------
 6 files changed, 51 insertions(+), 56 deletions(-)
 create mode 100644 include/uapi/linux/openat2.h


base-commit: 912dfe068c43fa13c587b8d30e73d335c5ba7d44

Comments

Aleksa Sarai Dec. 19, 2019, 10:55 a.m. UTC | #1
While openat2(2) is still not yet in Linus's tree, we can take this
opportunity to iron out some small warts that weren't noticed earlier:

  * A fix was suggested by Florian Weimer, to separate the openat2
    definitions so glibc can use the header directly. I've put the
    maintainership under VFS but let me know if you'd prefer it belong
    ot the fcntl folks.

  * Having heterogenous field sizes in an extensible struct results in
    "padding hole" problems when adding new fields (in addition the
    correct error to use for non-zero padding isn't entirely clear ).
    The simplest solution is to just copy clone(3)'s model -- always use
    u64s. It will waste a little more space in the struct, but it
    removes a possible future headache.

Aleksa Sarai (2):
  uapi: split openat2(2) definitions from fcntl.h
  openat2: drop open_how->__padding field

 MAINTAINERS                                   |  1 +
 fs/open.c                                     |  2 -
 include/uapi/linux/fcntl.h                    | 37 +----------------
 include/uapi/linux/openat2.h                  | 40 +++++++++++++++++++
 tools/testing/selftests/openat2/helpers.h     |  3 +-
 .../testing/selftests/openat2/openat2_test.c  | 24 ++++-------
 6 files changed, 51 insertions(+), 56 deletions(-)
 create mode 100644 include/uapi/linux/openat2.h


base-commit: 912dfe068c43fa13c587b8d30e73d335c5ba7d44
Christian Brauner Dec. 19, 2019, 11:19 a.m. UTC | #2
On Thu, Dec 19, 2019 at 09:55:28PM +1100, Aleksa Sarai wrote:
> While openat2(2) is still not yet in Linus's tree, we can take this
> opportunity to iron out some small warts that weren't noticed earlier:
> 
>   * A fix was suggested by Florian Weimer, to separate the openat2
>     definitions so glibc can use the header directly. I've put the
>     maintainership under VFS but let me know if you'd prefer it belong
>     ot the fcntl folks.
> 
>   * Having heterogenous field sizes in an extensible struct results in
>     "padding hole" problems when adding new fields (in addition the
>     correct error to use for non-zero padding isn't entirely clear ).
>     The simplest solution is to just copy clone(3)'s model -- always use
>     u64s. It will waste a little more space in the struct, but it
>     removes a possible future headache.

Am I imagining things or did I get the same patch series twice?

Christian
Aleksa Sarai Dec. 19, 2019, 1:41 p.m. UTC | #3
On 2019-12-19, Christian Brauner <christian.brauner@ubuntu.com> wrote:
> On Thu, Dec 19, 2019 at 09:55:28PM +1100, Aleksa Sarai wrote:
> > While openat2(2) is still not yet in Linus's tree, we can take this
> > opportunity to iron out some small warts that weren't noticed earlier:
> > 
> >   * A fix was suggested by Florian Weimer, to separate the openat2
> >     definitions so glibc can use the header directly. I've put the
> >     maintainership under VFS but let me know if you'd prefer it belong
> >     ot the fcntl folks.
> > 
> >   * Having heterogenous field sizes in an extensible struct results in
> >     "padding hole" problems when adding new fields (in addition the
> >     correct error to use for non-zero padding isn't entirely clear ).
> >     The simplest solution is to just copy clone(3)'s model -- always use
> >     u64s. It will waste a little more space in the struct, but it
> >     removes a possible future headache.
> 
> Am I imagining things or did I get the same patch series twice?

Not unless it's a coincidence -- I accidentally ran

  % git send-email *.patch [some flags] *.patch