libc-compat.h for <bits/fcntl-linux.h>
Commit Message
Hello everyone,
I've been doing some kernel hacking and added some new flags to the
Linux kernel. I want to use these flags in userland without having to in
an additional header (<asm-generic/fcntl.h>) and even then, there are
conflicts, because almost everything is already defined.
As such, I filed a feature request (20050) and was informed about
about the process to have compatibility.
I've attached a patch that shouldn't break anything. Incidentally,
everything in the Linux Kernel matches what is done by glibc.
If I need to provide any more information, then please let me know.
Regards,
Eric Neblock
Comments
On 08 May 2016 14:17, Eric Neblock wrote:
> I've been doing some kernel hacking and added some new flags to the
> Linux kernel. I want to use these flags in userland without having to in
> an additional header (<asm-generic/fcntl.h>) and even then, there are
> conflicts, because almost everything is already defined.
>
> As such, I filed a feature request (20050) and was informed about
> about the process to have compatibility.
>
> I've attached a patch that shouldn't break anything. Incidentally,
> everything in the Linux Kernel matches what is done by glibc.
>
> If I need to provide any more information, then please let me know.
it seems like your patch is reversed. please use the latest git instead
of a release tarball. `git diff` will make sure it's formatted correctly.
-mike
On 08 May 2016 22:22, Mike Frysinger wrote:
> On 08 May 2016 14:17, Eric Neblock wrote:
> > I've been doing some kernel hacking and added some new flags to the
> > Linux kernel. I want to use these flags in userland without having to in
> > an additional header (<asm-generic/fcntl.h>) and even then, there are
> > conflicts, because almost everything is already defined.
> >
> > As such, I filed a feature request (20050) and was informed about
> > about the process to have compatibility.
> >
> > I've attached a patch that shouldn't break anything. Incidentally,
> > everything in the Linux Kernel matches what is done by glibc.
> >
> > If I need to provide any more information, then please let me know.
>
> it seems like your patch is reversed. please use the latest git instead
> of a release tarball. `git diff` will make sure it's formatted correctly.
aaand you did that already. should have read the full thread first.
-mike
On Sun, May 8, 2016 at 3:17 PM, Eric Neblock <ceneblock@member.fsf.org> wrote:
> Hello everyone,
> I've been doing some kernel hacking and added some new flags to the
> Linux kernel. I want to use these flags in userland without having to in
> an additional header (<asm-generic/fcntl.h>) and even then, there are
> conflicts, because almost everything is already defined.
>
> As such, I filed a feature request (20050) and was informed about
> about the process to have compatibility.
>
> I've attached a patch that shouldn't break anything. Incidentally,
> everything in the Linux Kernel matches what is done by glibc.
Rather than this approach, why not have the glibc header include the
uapi header and rely on its definitions? This might need to be
conditional on a sufficiently new version of the uapi header being
available, but it is more future-proof.
zw
On 05/09/2016 07:47 AM, Zack Weinberg wrote:
> On Sun, May 8, 2016 at 3:17 PM, Eric Neblock <ceneblock@member.fsf.org> wrote:
>> Hello everyone,
>> I've been doing some kernel hacking and added some new flags to the
>> Linux kernel. I want to use these flags in userland without having to in
>> an additional header (<asm-generic/fcntl.h>) and even then, there are
>> conflicts, because almost everything is already defined.
>>
>> As such, I filed a feature request (20050) and was informed about
>> about the process to have compatibility.
>>
>> I've attached a patch that shouldn't break anything. Incidentally,
>> everything in the Linux Kernel matches what is done by glibc.
>
> Rather than this approach, why not have the glibc header include the
> uapi header and rely on its definitions? This might need to be
> conditional on a sufficiently new version of the uapi header being
> available, but it is more future-proof.
>
> zw
>
My only concern with that would be if someone is compiling for BSD,
Solaris, Cygwin, or some other *nix.
In the case of Cygwin, wouldn't everything *appear* to be Linux, but it
wouldn't have the headers?
Eric
On Mon, May 9, 2016 at 8:52 AM, Eric Neblock <ceneblock@member.fsf.org> wrote:
> On 05/09/2016 07:47 AM, Zack Weinberg wrote:
>> Rather than this approach, why not have the glibc header include the
>> uapi header and rely on its definitions? This might need to be
>> conditional on a sufficiently new version of the uapi header being
>> available, but it is more future-proof.
>
> My only concern with that would be if someone is compiling for BSD,
> Solaris, Cygwin, or some other *nix.
In that case, sysdeps/unix/sysv/linux/bits/fcntl-linux.h will not be
used at all.
zw
On 05/09/2016 07:53 AM, Zack Weinberg wrote:
> On Mon, May 9, 2016 at 8:52 AM, Eric Neblock <ceneblock@member.fsf.org> wrote:
>> On 05/09/2016 07:47 AM, Zack Weinberg wrote:
>>> Rather than this approach, why not have the glibc header include the
>>> uapi header and rely on its definitions? This might need to be
>>> conditional on a sufficiently new version of the uapi header being
>>> available, but it is more future-proof.
>>
>> My only concern with that would be if someone is compiling for BSD,
>> Solaris, Cygwin, or some other *nix.
>
> In that case, sysdeps/unix/sysv/linux/bits/fcntl-linux.h will not be
> used at all.
>
> zw
>
Just for my own sanity, I rechecked the INSTALL file of glibc and Linux
headers are required.
I'll update the patch shortly.
Eric
Zack Weinberg <zackw@panix.com> writes:
> Rather than this approach, why not have the glibc header include the
> uapi header and rely on its definitions? This might need to be
> conditional on a sufficiently new version of the uapi header being
> available, but it is more future-proof.
The kernel header cannot be used due to lack of name space sanity.
Andreas.
On 05/09/2016 03:06 PM, Andreas Schwab wrote:
> Zack Weinberg <zackw@panix.com> writes:
>
>> Rather than this approach, why not have the glibc header include the
>> uapi header and rely on its definitions? This might need to be
>> conditional on a sufficiently new version of the uapi header being
>> available, but it is more future-proof.
>
> The kernel header cannot be used due to lack of name space sanity.
Exactly. Without feature selection macros such as _GNU_SOURCE, the set
of macros which can be defined by <fcntl.h> is very limited.
Florian
On 09 May 2016 08:02, Eric Neblock wrote:
> On 05/09/2016 07:53 AM, Zack Weinberg wrote:
> > On Mon, May 9, 2016 at 8:52 AM, Eric Neblock <ceneblock@member.fsf.org> wrote:
> >> On 05/09/2016 07:47 AM, Zack Weinberg wrote:
> >>> Rather than this approach, why not have the glibc header include the
> >>> uapi header and rely on its definitions? This might need to be
> >>> conditional on a sufficiently new version of the uapi header being
> >>> available, but it is more future-proof.
> >>
> >> My only concern with that would be if someone is compiling for BSD,
> >> Solaris, Cygwin, or some other *nix.
> >
> > In that case, sysdeps/unix/sysv/linux/bits/fcntl-linux.h will not be
> > used at all.
>
> Just for my own sanity, I rechecked the INSTALL file of glibc and Linux
> headers are required.
well, they're required if you're building for a Linux target.
they aren't needed if you build for non-Linux targets.
-mike
On 05/08/2016 03:17 PM, Eric Neblock wrote:
> Hello everyone,
> I've been doing some kernel hacking and added some new flags to the
> Linux kernel. I want to use these flags in userland without having to in
> an additional header (<asm-generic/fcntl.h>) and even then, there are
> conflicts, because almost everything is already defined.
>
> As such, I filed a feature request (20050) and was informed about
> about the process to have compatibility.
>
> I've attached a patch that shouldn't break anything. Incidentally,
> everything in the Linux Kernel matches what is done by glibc.
>
> If I need to provide any more information, then please let me know.
You are on the right track.
As Florian pointed out our patch had issues (non-unified and reversed).
As Florian and Andreas point out, Zack's idea of just using the Linux
header won't work because of namespace cleanliness.
I assume the linux side of the patch is here:
https://lkml.org/lkml/2016/5/8/106
The next problem you have is that the glibc fcntl-linux.h header is
conditional on various standard defines. Therefore if the glibc headers
are included first, and some of these standard define are defined, then
you will still get conflicts. So you need to look at those details, for
example O_DIRECTORY is unconditionally defined if you include linux's
header, but it's only defined in some cases for glibc's headers. So if
you include glibc's headers first, then you need to conditionally define
O_DIRECTORY in the linux headers.
So you still have quite a ways to go. As a first submission to Linux
or glibc, you may wish to choose something easier to fix, or find
champions in each community that can help your patch get accepted.
Lastly, please review the contribution checklist:
https://sourceware.org/glibc/wiki/Contribution%20checklist
On 05/11/2016 09:15 AM, Carlos O'Donell wrote:
> On 05/08/2016 03:17 PM, Eric Neblock wrote:
>> Hello everyone,
>> I've been doing some kernel hacking and added some new flags to the
>> Linux kernel. I want to use these flags in userland without having to in
>> an additional header (<asm-generic/fcntl.h>) and even then, there are
>> conflicts, because almost everything is already defined.
>>
>> As such, I filed a feature request (20050) and was informed about
>> about the process to have compatibility.
>>
>> I've attached a patch that shouldn't break anything. Incidentally,
>> everything in the Linux Kernel matches what is done by glibc.
>>
>> If I need to provide any more information, then please let me know.
>
> You are on the right track.
>
> As Florian pointed out our patch had issues (non-unified and reversed).
>
> As Florian and Andreas point out, Zack's idea of just using the Linux
> header won't work because of namespace cleanliness.
>
> I assume the linux side of the patch is here:
> https://lkml.org/lkml/2016/5/8/106
>
> The next problem you have is that the glibc fcntl-linux.h header is
> conditional on various standard defines. Therefore if the glibc headers
> are included first, and some of these standard define are defined, then
> you will still get conflicts. So you need to look at those details, for
> example O_DIRECTORY is unconditionally defined if you include linux's
> header, but it's only defined in some cases for glibc's headers. So if
> you include glibc's headers first, then you need to conditionally define
> O_DIRECTORY in the linux headers.
>
> So you still have quite a ways to go. As a first submission to Linux
> or glibc, you may wish to choose something easier to fix, or find
> champions in each community that can help your patch get accepted.
>
> Lastly, please review the contribution checklist:
> https://sourceware.org/glibc/wiki/Contribution%20checklist
>
Hi Carlos,
I want to thank you for you kind and encouraging words.
That is the patch that I purposed to the Linux Kernel. In the instance
of O_DIRECTORY, it is conditionally #ifndef in the Linux kernel and the
purposed patch would add a conditional to glibc, so I'm confused on what
conflicts that brings.
I would be more than happy to work with anyone who wants to help me
get this patch going. I have it to a satisfactory condition for my
needs; however, if I'm going to share it, then it does need to be up to
standards.
When it comes to the checklist, I did notice that the patch Florian
corrected, did omit the ChangeLog entry. I didn't review the patch much
more than a quick glance, but I'm sure everything else is in there.
Regards,
Eric
Only in ./glibc-2.23_other/: build
***************
- 2016-05-08 Eric Neblock <ceneblock@member.fsf.org>
-
- * <bits/fcntl-linux.h>: Modified for kernel compability
-
2016-02-18 Adhemerval Zanella <adhemerval.zanella@linaro.org>
* version.h (RELEASE): Set to "stable".
Only in ./glibc-2.23: .gitattributes
Only in ./glibc-2.23: .gitignore
Only in ./glibc-2.23/po: be.mo
Only in ./glibc-2.23/po: bg.mo
Only in ./glibc-2.23/po: ca.mo
Only in ./glibc-2.23/po: cs.mo
Only in ./glibc-2.23/po: da.mo
Only in ./glibc-2.23/po: de.mo
Only in ./glibc-2.23/po: el.mo
Only in ./glibc-2.23/po: en_GB.mo
Only in ./glibc-2.23/po: eo.mo
Only in ./glibc-2.23/po: es.mo
Only in ./glibc-2.23/po: fi.mo
Only in ./glibc-2.23/po: fr.mo
Only in ./glibc-2.23/po: gl.mo
Only in ./glibc-2.23/po: hr.mo
Only in ./glibc-2.23/po: hu.mo
Only in ./glibc-2.23/po: ia.mo
Only in ./glibc-2.23/po: id.mo
Only in ./glibc-2.23/po: it.mo
Only in ./glibc-2.23/po: ja.mo
Only in ./glibc-2.23/po: ko.mo
Only in ./glibc-2.23/po: lt.mo
Only in ./glibc-2.23/po: nb.mo
Only in ./glibc-2.23/po: nl.mo
Only in ./glibc-2.23/po: pl.mo
Only in ./glibc-2.23/po: pt_BR.mo
Only in ./glibc-2.23/po: ru.mo
Only in ./glibc-2.23/po: rw.mo
Only in ./glibc-2.23/po: sk.mo
Only in ./glibc-2.23/po: sl.mo
Only in ./glibc-2.23/po: sv.mo
Only in ./glibc-2.23/po: tr.mo
Only in ./glibc-2.23/po: uk.mo
Only in ./glibc-2.23/po: vi.mo
Only in ./glibc-2.23/po: zh_CN.mo
Only in ./glibc-2.23/po: zh_TW.mo
***************
# include <bits/uio.h>
#endif
- /* If the user has added in the kernel header, then we use those definations */
- #ifndef __UAPI_DEF_FCNTL_H
- #define __BITS_FCNTL_LINUX_H 1
/* open/fcntl. */
#define O_ACCMODE 0003
#define O_RDONLY 00
#define O_WRONLY 01
#define O_RDWR 02
- #endif
-
#ifndef O_CREAT
# define O_CREAT 0100 /* Not fcntl. */
#endif
***************
last reference to the the file description against which they were acquired
is put. */
#ifdef __USE_GNU
- #ifndef __UAPI_DEF_FCNTL
# define F_OFD_GETLK 36
# define F_OFD_SETLK 37
# define F_OFD_SETLKW 38
! #endif /* __UAPI_DEF_FCNTL */
! #endif /* __USE_GNU */
#ifdef __USE_LARGEFILE64
# define O_LARGEFILE __O_LARGEFILE
last reference to the the file description against which they were acquired
is put. */
#ifdef __USE_GNU
# define F_OFD_GETLK 36
# define F_OFD_SETLK 37
# define F_OFD_SETLKW 38
! #endif
#ifdef __USE_LARGEFILE64
# define O_LARGEFILE __O_LARGEFILE
***************
# endif
#endif
- #ifndef __UAPI_DEF_FCNTL_H
/* Values for the second argument to `fcntl'. */
#define F_DUPFD 0 /* Duplicate file descriptor. */
#define F_GETFD 1 /* Get file descriptor flags. */
#define F_SETFD 2 /* Set file descriptor flags. */
#define F_GETFL 3 /* Get file status flags. */
#define F_SETFL 4 /* Set file status flags. */
- #endif
#ifndef __F_SETOWN
# define __F_SETOWN 8
***************
#endif
#if defined __USE_UNIX98 || defined __USE_XOPEN2K8
- #ifndef __UAPI_DEF_FCNTL_H
# define F_SETOWN __F_SETOWN /* Get owner (process receiving SIGIO). */
# define F_GETOWN __F_GETOWN /* Set owner (process receiving SIGIO). */
! #endif /* __UAPI_DEF_FCNTL_H */
! #endif /* __USE_UNIX98 || __USE_XOPEN2K8 */
#ifndef __F_SETSIG
# define __F_SETSIG 10 /* Set number of signal to be sent. */
#endif
#if defined __USE_UNIX98 || defined __USE_XOPEN2K8
# define F_SETOWN __F_SETOWN /* Get owner (process receiving SIGIO). */
# define F_GETOWN __F_GETOWN /* Set owner (process receiving SIGIO). */
! #endif
#ifndef __F_SETSIG
# define __F_SETSIG 10 /* Set number of signal to be sent. */
***************
#endif
#ifdef __USE_GNU
- #ifndef __UAPI_DEF_FCNTL_H
# define F_SETSIG __F_SETSIG /* Set number of signal to be sent. */
# define F_GETSIG __F_GETSIG /* Get number of signal to be sent. */
# define F_SETOWN_EX __F_SETOWN_EX /* Get owner (thread receiving SIGIO). */
# define F_GETOWN_EX __F_GETOWN_EX /* Set owner (thread receiving SIGIO). */
! #endif /* __UAPI_DEF_FCNTL_H */
! #endif /* __USE_GNU */
#ifdef __USE_GNU
# define F_SETLEASE 1024 /* Set a lease. */
#endif
#ifdef __USE_GNU
# define F_SETSIG __F_SETSIG /* Set number of signal to be sent. */
# define F_GETSIG __F_GETSIG /* Get number of signal to be sent. */
# define F_SETOWN_EX __F_SETOWN_EX /* Get owner (thread receiving SIGIO). */
# define F_GETOWN_EX __F_GETOWN_EX /* Set owner (thread receiving SIGIO). */
! #endif
#ifdef __USE_GNU
# define F_SETLEASE 1024 /* Set a lease. */
***************
close-on-exit set. */
#endif
- #ifndef __UAPI_DEF_FCNTL_H
/* For F_[GET|SET]FD. */
#define FD_CLOEXEC 1 /* Actually anything with low bit set goes */
- #endif
#ifndef F_RDLCK
/* For posix fcntl() and `l_type' field of a `struct flock' for lockf(). */
***************
# define F_SHLCK 8 /* or 4 */
#endif
- #ifndef __UAPI_DEF_FCNTL_H
#ifdef __USE_MISC
/* Operations for BSD flock, also used by the kernel implementation. */
# define LOCK_SH 1 /* Shared lock. */
***************
# define LOCK_NB 4 /* Or'd with one of the above to prevent
blocking. */
# define LOCK_UN 8 /* Remove lock. */
! #endif /* __USE_MISC */
#ifdef __USE_GNU
# define LOCK_MAND 32 /* This is a mandatory flock: */
# define LOCK_READ 64 /* ... which allows concurrent read operations. */
# define LOCK_WRITE 128 /* ... which allows concurrent write operations. */
# define LOCK_RW 192 /* ... Which allows concurrent read & write operations. */
! #endif /* __USE_MISC */
! #endif /* __UAPI_DEF_FCNTL_H */
#ifdef __USE_GNU
/* Types of directory notifications that may be requested with F_NOTIFY. */
# define LOCK_NB 4 /* Or'd with one of the above to prevent
blocking. */
# define LOCK_UN 8 /* Remove lock. */
! #endif
#ifdef __USE_GNU
# define LOCK_MAND 32 /* This is a mandatory flock: */
# define LOCK_READ 64 /* ... which allows concurrent read operations. */
# define LOCK_WRITE 128 /* ... which allows concurrent write operations. */
# define LOCK_RW 192 /* ... Which allows concurrent read & write operations. */
! #endif
#ifdef __USE_GNU
/* Types of directory notifications that may be requested with F_NOTIFY. */