From: Mike Frysinger <vapier@gentoo.org>
To: Jeff Layton <jlayton@redhat.com>
Cc: libc-alpha@sourceware.org, linux-fsdevel@vger.kernel.org,
chrubis@suse.cz
Subject: Re: [glibc PATCH] fcntl-linux.h: add F_OFD_*32 constants
Date: Thu, 18 Aug 2016 09:00:26 -0700 [thread overview]
Message-ID: <20160818160026.GI21655@vapier.lan> (raw)
In-Reply-To: <1471528199.2504.5.camel@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
On 18 Aug 2016 09:49, Jeff Layton wrote:
> On Thu, 2016-08-18 at 06:04 -0700, Mike Frysinger wrote:
> > On 18 Aug 2016 08:03, Jeff Layton wrote:
> > > --- a/sysdeps/unix/sysv/linux/bits/fcntl-linux.h
> > > +++ b/sysdeps/unix/sysv/linux/bits/fcntl-linux.h
> > > @@ -127,11 +127,20 @@
> > > This means that they are inherited across fork or clone with CLONE_FILES
> > > like BSD (flock) locks, and they are only released automatically when the
> > > last reference to the the file description against which they were acquired
> > > - is put. */
> > > + is put. */
> > > #ifdef __USE_GNU
> > > > > -# define F_OFD_GETLK 36
> > > > > -# define F_OFD_SETLK 37
> > > > > -# define F_OFD_SETLKW 38
> > > +# if __OFF_T_MATCHES_OFF64_T || defined __USE_FILE_OFFSET64
> > > > > +# define F_OFD_GETLK 36
> > > > > +# define F_OFD_SETLK 37
> > > > > +# define F_OFD_SETLKW 38
> > > +# else
> > > > > +# define F_OFD_GETLK32 39
> > > > > +# define F_OFD_SETLK32 40
> > > > > +# define F_OFD_SETLKW32 41
> > > > > +# define F_OFD_GETLK F_OFD_GETLK32
> > > > > +# define F_OFD_SETLK F_OFD_SETLK32
> > > > > +# define F_OFD_SETLKW F_OFD_SETLKW32
> > > +# endif
> > > #endif
> >
> > i think we should define *64 and *32 variants all the time, and
> > then route the F_OFD_GETLK/etc... to them based on compile mode.
>
> Sorry, I don't quite understand here. The whole point is that the
> existing F_OFD_* constants are already implicitly 64-bit. Why do we
> need separate constants postfixed with "64" that no one will ever use?
you're making them not explicitly 64-bit when off_t!=off64_t.
all the other commands in this file have used the convention:
<cmd>: automatically 32-bit or 64-bit
<cmd>64: always 64-bit
so the header would do:
#define F_OFD_GETLK64 36
#define F_OFD_SETLK64 37
#define F_OFD_SETLKW64 38
#if __OFF_T_MATCHES_OFF64_T || defined __USE_FILE_OFFSET64
# define F_OFD_GETLK F_OFD_GETLK64
# define F_OFD_SETLK F_OFD_SETLK64
# define F_OFD_SETLKW F_OFD_SETLKW64
#else
# define F_OFD_GETLK 39
# define F_OFD_SETLK 40
# define F_OFD_SETLKW 41
#endif
the defines deviate a bit from the names used on the kernel side,
but we've already done that, and you're proposed patch does too.
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2016-08-19 0:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-18 12:03 [glibc PATCH] fcntl-linux.h: add F_OFD_*32 constants Jeff Layton
2016-08-18 13:04 ` Mike Frysinger
2016-08-18 13:49 ` Jeff Layton
2016-08-18 16:00 ` Mike Frysinger [this message]
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=20160818160026.GI21655@vapier.lan \
--to=vapier@gentoo.org \
--cc=chrubis@suse.cz \
--cc=jlayton@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-fsdevel@vger.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.