Hi,

On 4/11/23 22:11, aitor wrote:
> I have a new libudev-compat that works with both eudev and vdev. In other words, the shared library has a dual behavior
> that will depend on whether /dev is in devtmpfs or tmpfs. This is the criterion that will determine the way to go for
> libudev-compat. IMHO, this duality is advisable because (since chimaera) libapt depends on libudev, and changes from
> libeudev1 to the old libudev1-compat or vice versa may become a bit riskie, although I've been doing this way for years
> in gnuinos. Of course, once libudev-compat has been installed it's still possible to revert the situation and reinstall
> libeudev if you wish, despite the fact that the earlier will work fine for eudev as well.

I would imagine that some of you may wonder why `tmpfs` and not `devtmpfs`. So, maybe this point diserves some clarifications.
Indeed, I myself have often wondered why Jude Nelson was using `/dev` in `tmpfs`. As explained in the README file: "the Linux
port of vdev interoperates with but does not depend on the `devtmpfs` filesystem." So, one possible reason might be that
vdev was developed with portability in mind, not to mention the compatibility with linux versions that don't have the config
option CONFIG_DEVTMPFS.

On the other hand, bear in mind that `devtmpfs` is an improved `devfs`, a filesystem with automated device nodes populated by the kernel.
And although vdev does work with `devtmpfs`, it will do in a different manner in comparison with `tmpfs`, because in the case of the former
it's the kernel driver which maintains device nodes. This means that you don't have to have any device manager for that. Instead the
kernel populates the appropriate information based on the known devices.

Looking at the code of the function "vdev_os_init()" implemented in:

https://github.com/jcnelson/vdev/blob/master/vdevd/os/linux.c

you can see the lines:

   rc = vdev_linux_mountpoint_on_devtmpfs( os_ctx->state->mountpoint );

   if( rc > 0 )

      vdev_config_set_OS_quirk( os_ctx->state->config->OS_quirks, VDEV_OS_QUIRK_DEVICE_EXISTS );

establishing a different behavior for `devtmpfs`, ruled by the variable "OS_quirks". The value of VDEV_OS_QUIRK_DEVICE_EXISTS is defined
in libvdev/config.h as follows (pay attention to the attached comment):

#define VDEV_OS_QUIRK_DEVICE_EXISTS  0x1  // set this bit if the OS already has the device file--i.e. vdevd is not expected to create it

In other words, when `/dev` is in `devtmpfs` device nodes aren't created. It is therefore not surprising that Jude Nelson considered `tmpfs`
more accurate that `devtmpfs` for testing purposes, in order to ensure that all device nodes were effectively created by the program as expected.

Out of sheer inertia, I followed using `tmpfs` rather than `devtmpfs`, in the same way that Jude Nelson did. But, on top of the explanations above,
there is still another reason...

Udev stores device metadata in `/run/udev`, whereas vdev stores it in `/dev/metadata`. And `devtmpfs` should only contain device-nodes or links,
both stored as directory entries without data inodes entries [*]. Correct me if I'm mistaken.

With all this in mind, at time I have doubts: tmpfs or devtmpfs?

Bear in mind, on the other hand, that recently I integrated the `eventfs` filesystem in `libudev-compat` (mounted at `/dev/metadata/udev/events`)
that ships with a garbage-collector that didn't exist when Jude Nelson was still working on vdev. Perhaps he was planning to move device metadata
from /dev to /run, once integrated the `eventfs` filesystem, who knows.

Cheers,

Aitor.

[*] excluding /dev/shm