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 <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
>>>
>>>
>>> _______________________________________________
>>> Dng mailing list
>>> Dng@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
::
Re: [Dng] vdev status updates
