Sounds all very clean and nice. Kudos to Jude! Looking forward to using vdev* eventually
/j On Wed 18 March 2015 10:43:06 Jude Nelson wrote: > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
