Le 18/03/2015 16:37, Joerg Reisenweber a écrit :
Sounds all very clean and nice.
Kudos to Jude! Looking forward to using vdev* eventually
/j
+1 :-) Didier
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
_______________________________________________
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