:: Re: [DNG] vdev status update: event…
Top Page
Delete this message
Reply to this message
Author: Jude Nelson
Date:  
To: shraptor
CC: dng@lists.dyne.org
Subject: Re: [DNG] vdev status update: eventfs
Hi shraptor,

On Wed, Sep 23, 2015 at 1:30 PM, shraptor <shraptor@???> wrote:

> On 2015-09-23 17:14, Jude Nelson wrote:
>
>> @shraptor
>>
>>> So how to get eventfs going with vdev.
>>> ./eventfs /run/udev
>>> or where should eventfs be mounted?
>>> Eventfs mounting will not be handled by vdev, right?
>>>
>>
>> Vdev won't set up eventfs. I'll ship a sysv init script with it that
>> will mount it automatically (probably shortly after init starts, since
>> libudev-compat programs will need it relatively early in the boot
>> process).
>>
>
> Is it a hard dependency on eventfs?
>


Vdev does not need eventfs. Libudev-compat benefits from using it, but
does not need it for correct operation. It's a soft dependency.

Or will some functionality work without eventfs?
>


Yes--it will remain possible to use libudev-compat without eventfs.


>
> Is it the same data as was made availible in /run/udev before??
>


No, eventfs will handle the contents of /dev/metadata/udev/events and
/dev/events. If you look in /dev/metadata/udev/events, you'll see that
libudev-compat processes will have created a bunch of directories
there--one for each struct udev_monitor--into which vdev's udev-compat.sh
helper writes device events. Currently, there is no straightforward and
automatic way to clean this directory out, but doing so is nevertheless
necessary since the directories for a process's struct udev_monitor
instances will persist after the process dies (I've written a script to
clean the dead directories out periodically, but it's not perfect). By
having libudev-compat clients write to eventfs, we can ensure that these
directories are automatically removed after the process that created them
dies.

-Jude


>
>
>
>> I was planning on having it mounted on /run/events, in order to make
>> it available as a generic IPC system for other programs to use for
>> their own purposes. Eventfs isn't specific to vdev; I'm hoping to
>> use it as a partial alternative to dbus. I'm open to alternative
>> mount points, though.
>>
>> @jaromil
>>
>>> Amazing news. noone here doubts you are continuing to build up on
>>>
>> the
>>
>>> solid foundations you laid, I am sure vdev will become a relevant
>>> component for many mission-critical GNU/Linux system installations.
>>>
>>
>> Please do not hesitate to ask for anything you need in terms of
>>> infrastructure and funding we can contribute from our donation pot.
>>>
>>
>> Thank you for your generous offer! I think I'm fine for now insofar
>> as development infrastructure, but one thing that will be particularly
>> tricky is creating the packaging scripts needed to replace udev
>> automatically, but without rendering the host unbootable if something
>> goes wrong.
>>
>> Thanks,
>> Jude
>>
>> On Tue, Sep 22, 2015 at 6:20 AM, vmlinux <vmlinux@???> wrote:
>>
>> Great news! Thank you for all your efforts!
>>>
>>> On September 21, 2015 9:44:12 PM CDT, Jude Nelson
>>> <judecn@???> wrote:
>>>
>>> ::I'm pleased to announce the availability of eventfs
>>>
>>> --
>>> Sent from a Mobile device.
>>>
>>
>>
>> _______________________________________________
>> 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
>