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 <k...@in2p3.fr> 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 <reisenwe...@web.de >> <mailto:reisenwe...@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@lists.dyne.org <mailto:Dng@lists.dyne.org> >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> >> >> >> >> _______________________________________________ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > > > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
