2015-11-06 4:27 GMT+01:00 Waldemar Brodkorb wbx@uclibc-ng.org:
Hi Thomas, Thomas Petazzoni wrote,
Bartosz, Waldemar,
On Wed, 14 Oct 2015 17:14:00 +0200, Bartosz Golaszewski wrote:
Add support for fanotify_init() and fanotify_mark() syscalls. The header file is taken from glibc.
Signed-off-by: Bartosz Golaszewski bartekgola@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_defc....
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.
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
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.