On Mon, Dec 26, 2016 at 5:32 PM, Rob Landley <r...@landley.net> wrote: > On 12/26/2016 08:05 AM, Martin Tippmann wrote: >> On Sun, Dec 25, 2016 at 9:01 PM, Denys Vlasenko >> So TL;DR: procd is fine for init but having runit/runsvdir easily >> usable would be a nice feature to have! > > This implies that systemd should also be an option. As long as there's > no standard init in the distro, might as well do them all? (Seems > counterproductive to me.)
Hi, I'm not a dev and I just shared my personal 'would be nice to have' opinion. I appreciate the work on procd and netifd and ubus and a lot of thought went into it and it serves almost all usecases pretty well. afaik (please correct me if I'm wrong) systemd has some properties that make it a bad fit for something like a 32mb/4mb flash router: - glibc only (i.e. you are on your own with musl, good luck, patches not welcome) - hard dbus dependency (maybe bus1 in the future might make this obsolete). dbus depends on glibc, glib? all 'huge' deps for a small router. - udev is mandatory? - cgroups are mandatory? (+some other kernel stuff that is off by default on LEDE/OpenWRT) - <lot's of other stuff> I don't see any benefits and we have almost everything systemd does with procd,netifd,ubus Adding runit+runsvdir to a squashfs image are a few kb at best - last time I checked the image size didn't even change. Some practical example where runit might be useful (if you know how to do this with procd, please tell me :) - we have on our mesh network a VPN client (vtun) that starts when wan is up (via hotplug) but connectivity to the mesh network depends on olsr working. - at the moment there is some cumbersome cron logic shellscript hell that tries to check that a) vtun is working, b) olsr is working - writing a runit sv check script for vtun that checks for the correct olsr neighbours and that restarts vtun if no neighbours are found is pretty simple with runit. symlink the check for runwhen in the /etc/hotplug.d/vtun-wan script and then unlink on ifdown event. runit picks up the symlink and does the right thing. So there is the vtun connection and the 'sv ./etc/services/vtun check' script that checks olsr neighbors - This gives you seperation of concerns, it's unixy, it's only shell and it's something you can reason about. So what I'd like to have is something like adding events to runit - if netifd realizes there is a link loss on the wan interface I want to trigger somewhere sv stop /etc/services/vtun I don't need systemd. This might be useful for bigger machines like some NAS devices where the users are familiar with systemd but IMHO procd+netifd+ubus are superior in every aspect to systemd for these low end router use cases. But marrying runit+ubus+netifd+procd would _really_ solve some real world usecases we have in a unixy, reasonable way. I'm open for debate and discussion but this would provide a lot of flexibility for a rather low cost/overhead - be it memory/flash. Unfortunatly this mail is all talk and no walk and figuring out a sane procd/netifd <-> runit interface is some rather hard problem if you want a good solution. But it's IMHO a path worth going because it provides a unixy, sane, ressource-efficient, powerful interface without politics. just my <amount> cents Martin _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
