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... Looking at path_is_mount_point() suggests ENOSYS is used? Or is that function checking for the wrong error code? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
