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 <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
::
Re: [Dng] vdev status updates
