[systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf

[Lennart Poettering]

On Thu, 24.04.14 02:47, Zbigniew Jędrzejewski-Szmek (zbyszek at 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