Hi Didier,

> It's very good to use inotify, because it's a standard Linux tool (don't
know for other nixes), not yet-another-interface. This way DEs shouldn't
have any concern implementing it.

That's the plan :) Like udisks2, NetworkManager, and upower, vdevd-user
(or something like it) offer DEs the ability to have their DE-specific
device-handling programs executed when a device gets plugged in or pulled
out.

inotify is Linux-specific, kqueue is BSD-specific, and /dev/poll is
Solaris-specific. However, libkqueue ports the BSD kqueue interface to
Linux and Solaris, so using that library as a way to watch /dev for changes
would let vdevd-user be portable (i.e. the Linux port of libkqueue is
implemented with inotify(2)).

> This means you will provide support for inotify in vdevfs? AFAIK there
isn't in every filesystem, eg sysfs.

Interestingly, inotify(2) is implemented by the kernel's VFS, not the
filesystem implementation (this is true for FUSE as well). The only way
the VFS learns when files and directories change is when a userspace
program makes a VFS syscall. This is why you can't use inotify(2) to watch
procfs and sysfs for changes--the changes to the kernel state these
filesystems represent are not routed through the VFS layer.

This isn't a problem for vdev, since vdevd makes the VFS syscalls--it's
vdevd that actually triggers the inotify(2) events, not vdevfs. This means
you don't need to use vdevfs for vdevd-user to work--inotify(2) will work
regardless of whatever filesystem /dev resides on.

-Jude

On Wed, Mar 18, 2015 at 6:01 AM, Didier Kryn <kryn@???> wrote:

>     It's very good to use inotify, because it's a standard Linux tool
> (don't know for other nixes), not yet-another-interface. This way DEs
> shouldn't have any concern implementing it.

>

>     This means you will provide support for inotify in vdevfs? AFAIK there
> isn't in every filesystem, eg sysfs.

>

>     Didier

>
> Le 17/03/2015 09:48, Jude Nelson a écrit :
>
>> > How would that "watching" work?
>>
>> vdevd-user would have an inotify(2)-based back-end (hopefully via
>> libkqueue, so it would be portable). The back-end would set up inotify
>> watches on /dev and its descendant directories, and translate creat(2) and
>> unlink(2) events from inotify into a vdev-specific device event with the
>> relevant information (e.g. by querying the device metadata that the
>> system's vdevd puts into /dev/vdev/...).
>>
>> -Jude
>>
>> On Tue, Mar 17, 2015 at 1:30 AM, Joerg Reisenweber <reisenweber@???
>> <mailto:reisenweber@web.de>> wrote:
>>

>>     On Tue 17 March 2015 01:20:43 Jude Nelson wrote:
>>     > What I'm considering doing is creating vdevd-user, a build of
>>     > vdevd with a backend for watching the contents of /dev, instead of
>>     > listening to the kernel for device events.

>>

>>     How would that "watching" work?

>>

>>     /jOERG
>>     _______________________________________________
>>     Dng mailing list
>>     Dng@??? <mailto:Dng@lists.dyne.org>
>>     https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

>>
>>
>>
>>
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>