On Thu, Apr 24, 2014 at 06:35:58AM +0200, Lennart Poettering wrote: > On Thu, 24.04.14 02:47, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > Supporting less reliable operation modes for something that just needs > > > to be configured in the kernel seems the wrong approach, especially > > > when it involves filesystem operations on user data like tmpfiles > > > does, we just depend on CONFIG_FHANDLE. > > OK, what about this: > > > > -------8<-------------------------------------------------------------- > > > > udev: warn when name_to_handle_at is not implemented > > > > We have a bunch of reports from people who have a custom kernel and > > are confused why udev is not running. Issue a warning on > > error. Barring an error in the code, the only error that is possible > > is ENOSYS. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1072966 > > > > diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c > > index 0a2ab82..b9972c9 100644 > > --- a/src/libudev/libudev-monitor.c > > +++ b/src/libudev/libudev-monitor.c > > @@ -115,9 +115,11 @@ static bool udev_has_devtmpfs(struct udev *udev) { > > int r; > > > > r = name_to_handle_at(AT_FDCWD, "/dev", &h.handle, &mount_id, 0); > > - if (r < 0) > > + if (r < 0) { > > + if (errno != EOPNOTSUPP) > > + udev_err(udev, "name_to_handle_at on /dev: %m\n"); > > return false; > > - > > + } > > > > f = fopen("/proc/self/mountinfo", "re"); > > if (!f) > > > > -------8<-------------------------------------------------------------- > > > > Note that this makes missing name_to_handle_at behave similar to failing > > socket(), etc, so seems to be in line with surrounding code. > > Have you checked that EOPNOTSUPP is really the error that is returned by > name_to_handle_at() if the kernel has the entire syscall disabled? Note > that there are two different cases to distuingish here: a file system > not supporting the operation, and the kernel not supporting the > syscal... It's warning on everything except EOPNOTSUPP. My reasoning is:
EOPNOTSUPP -> syscall supported, but wrong fs type, -> return false ENOSYS -> syscall not supported -> warn and return false any other error -> memory error or other major screw-up -> warn and return false > Looking at path_is_mount_point() suggests ENOSYS is used? Or is that > function checking for the wrong error code? Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel