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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
