Hi Enrico,

> yeah, sooner or later there'll need to do a full fork.
> we should get in contact with them (I just posted a first mail onto
> their maillist).

I'd be curious to know what they have to say, since Devuan will likely ship
with udev or eudev for now. I hope it doesn't come to that--I hope the
changes the systemd folks have planned regarding kdbus and systemd don't
affect the "core" eudev functionality to the point where the eudev
developers can't accept patches from udev.

> ACK. But I'm not sure whether that has to be an 100% drop-in replacement
> for now. Trying to do so carries the risk of just copying bad design
> decisions - for example, I dont think that tools like file managers
> should directly call the device manager.

Detecting new storage devices with a dynamic device manager is pretty
straightforward: watch /dev/ for new device nodes, and then check that the
new device node is a block device. No need for libudev :)

It's not as straightforward with network cards, however, or any device that
doesn't have a major/minor number. IIRC, udev doesn't take any filesystem
actions when a network card appears, but libudev allows programs to listen
for device discoveries from udev. I plan to have vdev record somewhere in
the filesystem that it knows about the device when discovered, even if it
just puts some useful metadata into a regular file, so programs can simply
query the filesystem for any device change. Much simpler IMHO.

> That's an interesting approach.
> OTOH, what happens when runfs process dies (or needs to be restarted
> for some reason) ?

At the time of this writing, the PID files get lost along with the
knowledge of which program created what (not desirable, I realize). I've
opened an issue for this--I'll update runfs to record its information to
the filesystem beneath it, so it can be reconstructed on recovery.

> For the PID management, we IMHO can realy on procfs, maybe just having
> an little deamon which cleans up stale pidfiles from time to time,
> before a possible PID wraparound happens.

I considered that approach. The problem I wanted to solve was avoiding
other programs reading and acting upon invalid PID files (such as init
scripts are prone to do). Runfs does not have this problem, since it
checks the PID file's validity on stat() and readdir(), and atomically
culls the file if it is invalid (and reports to the caller that the file
doesn't exist). Also, procfs doesn't exist on OpenBSD, and I wanted
something that would work there :)

> Additionally, we could also just open an socket/fifo, which will get
> disconnected when the opening process dies. That stuff can be easily
> put into an small library, with some small command line tool.

Yes, but that requires patching countless existing programs and libraries,
and it can clutter the filesystem with "dead" sockets/fifos that would have
to be cleaned up. It also doesn't make the problem of learning the PID of
the process that created it any easier--you'd still need to put a PID file
somewhere, or include the PID in the socket/fifo name (but that would
require you to test all socket/fifos for the one that is still "alive" to
find the right PID, which can be expensive).

-Jude




On Wed, Dec 31, 2014 at 9:03 AM, Enrico Weigelt, metux IT consult <
enrico.weigelt@???> wrote:

> On 31.12.2014 10:59, Jude Nelson wrote:
>
> Hi,
>
> > However, future entanglements with systemd and kdbus could make this
> > much harder, to the point that eudev has no choice but to diverge
> > from udev, thereby increasing the maintenance burden considerably.
>
> yeah, sooner or later there'll need to do a full fork.
> we should get in contact with them (I just posted a first mail onto
> their maillist).
>
> > This precarious situation is one motivating factor in my creating
> > vdev--we must have a drop-in replacement for udev beyond the
> > influence of the systemd developers that's ready to go in case
> > maintaining eudev suddenly becomes intractable.
>
> ACK. But I'm not sure whether that has to be an 100% drop-in replacement
> for now. Trying to do so carries the risk of just copying bad design
> decisions - for example, I dont think that tools like file managers
> should directly call the device manager.
>
> > I have a partial solution to this, though--I've written a filesystem
> > called runfs [1] that has the property that once a process dies, runfs
> > automatically unlinks all of the files it created in it. This way,
> > I can start a daemon and have it write a PID file to runfs, and then
> > I can check to see if the daemon is still running simply by stat'ing
> > the PID file (it will not be present if the daemon has died). It does
> > not need to use cgroups to work, and programs can benefit from runfs
> > without knowing that they're using it :)
>
> That's an interesting approach.
> OTOH, what happens when runfs process dies (or needs to be restarted
> for some reason) ?
>
> Several years ago, I patched portmap to keep its mapping table directly
> within the filesystem, so it can be restarted anytime (in fact, it
> doesn't even need to run permanently that way - can be started on-demand
> via inetd and die after some idle timeout).
>
> For the PID management, we IMHO can realy on procfs, maybe just having
> an little deamon which cleans up stale pidfiles from time to time,
> before a possible PID wraparound happens.
>
> Additionally, we could also just open an socket/fifo, which will get
> disconnected when the opening process dies. That stuff can be easily
> put into an small library, with some small command line tool.
>
>
> cu
> --
> Enrico Weigelt,
> metux IT consulting
> +49-151-27565287
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>