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 < [email protected]> 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 > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
