6 Nov
2015
6 Nov
'15
3:27 a.m.
Hi Thomas,
Thomas Petazzoni wrote,
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.