On 17/04/15 06:00, Jude Nelson wrote:
> Hi Anto,
>
> I just committed preliminary support for using vdevd with devtmpfs.
> vdevd should automatically detect whether or not devtmpfs is mounted
> on /dev, and nevertheless run device setup scripts (by using its own
> device metadata tree in /dev/vdev/ to see whether or not the device
> was actually processed).
>
> NB for developers: this problem isn't specific to Linux--I expect to
> encounter it with FreeBSD as well, since it has a full-blown in-kernel
> devfs. vdevd will keep track of "OS quirks" in the future--one of
> which is the "Device Already Exists" quirk, whereby vdevd simply
> expects the OS to provide the device file (regardless of the
> mechanism). The Linux-specific vdevd back-end now checks to see if
> vdevd will create files on a devtmpfs filesystem, and enables that
> quirk if so.
>
> Funny, undocumented (!!) discovery: the devtmpfs filesystem type (see
> statfs(2)) is the same (!!) as the tmpfs filesystem type, despite
> being a fundamentally different filesystem. I'm surprised that this
> wasn't caught during the devtmpfs code review--guess I'll have to file
> a bug report. Anyway, if you find yourself wondering why vdev has to
> detect devtmpfs by parsing /proc/mounts and verifying that the
> realpath of the mountpoint is the same as or is a subdirectory of a
> devtmpfs mountpoint, that's why--we (currently) can't rely on the
> f_fsid in statfs(2) or statvfs(2).
>
> Thanks,
> Jude
>

Hello Jude,

Before I start pulling your latest commit, could you please let me know
from which source should I pull that? Should it be from
https://git.devuan.org/pkgs-utopia-substitution/vdev or
https://github.com/jcnelson/vdev? So far I have been using the one on
github.com.

Cheers,

Anto