6 Nov
2015
6 Nov
'15
10:40 a.m.
2015-11-06 4:27 GMT+01:00 Waldemar Brodkorb <wbx(a)uclibc-ng.org>rg>:
Hi Thomas,
Thomas Petazzoni wrote,
Hi Waldemar, Thomas,
in fanotify.c we have:
#ifdef __NR_fanotify_init
(...)
#endif
and
#ifdef __NR_fanotify_mark
(...)
#endif
What about making #include <linux/fanotify.h> conditional with:
#if defined(__NR_fanotify_init) && defined(__NR_fanotify_mark)
# include <linux/fanotify.h>
(...)
#endif
Otherwise including fanotify defines like musl does sounds good.
--
Best regards,
Bartosz Golaszewski
Bartosz, Waldemar,
On Wed, 14 Oct 2015 17:14:00 +0200, Bartosz Golaszewski wrote:
Yeah, I prefer 1), too. I don't like new kconfig symbols for just
saving a few bytes. I think we should just include the required
defines in fanotify.h, like musl is doing it?
http://git.musl-libc.org/cgit/musl/tree/include/sys/fanotify.h
@Bartosz: what do you think?
best regards
Waldemar Add support for fanotify_init() and
fanotify_mark() syscalls. The header
file is taken from glibc.
Signed-off-by: Bartosz Golaszewski <bartekgola(a)gmail.com>
This commit breaks the uClibc-ng when fairly old (2.6.35) kernel
headers are used, because the fanotify system call wasn't available at
that time, so <linux/fanotify.h> doesn't exist.
See
http://jenkins.free-electrons.com/job/buildroot/configurations=mx53loco_def….
It started failing since we updated to uClibc-ng 1.0.8.
I am not sure what's the policy of uClibc-ng on that respect:
1/ Should the fanotify() implementation in uClibc-ng be made
conditional on the availability of the corresponding system calls and
header files in the kernel headers.
2/ Or should fanotify be behind some kconfig option?
I would personally prefer (1), so that it gets automatically enabled
when available, and disabled otherwise. (2) would be less practical for
projects like Buildroot.