On 26.10.2011 13:07, Juergen Daubert wrote:
On Tue, Oct 25, 2011 at 03:00:15PM +0200, Michal Soltys wrote:
Ok, as promised, this is fresh approach to initscripts. Perhaps a few rough edges here and there, but is thoroughly tested (modulo just-a-moment ago minor changes I did)
thanks a lot, that was a expensive work ;)
At a first, coarse sight I like it, but it's rather complicated compared to our current solution. A quick wc shows that we have about quad the lines, not sure whether this might be too complicated for CRUX or not. I'd really like to hear the opinions of the other core/opt maintainers here.
The complication (though it's for the most part just much more corner-case-resilient code) mainly lies in rc.engine/ subdirectory. For example, what previously was just mount <...>, now checks if it is mounted, remounts to sanitize options, etc. Or better example - in rc.engine/all - functions responsible for stopping/starting services will not wait endlessly for broken or unresponsive rc.d script and kill its process group. And there're also some potentially useful prefixes added (start asynchronously, ignore service). Umount configuration is far more roboust as well. ITOW, what was previously done inline - as one or two liners - now calls "fatter" functions doing stuff much more thoroughly. Overall, the layout is: rc.engine/ lib - small helper functions all - common functions across different runlevels ckld - tiny kmsg logger, when normal syslog is not active sysinit, ... - "fat" functions doing what main rc scripts used to do inline rc.hook/ all/ - common hooks, currently post-umount (stage1) only sysinit/, ... - custom stuff configurable (with legacy symlink from /etc - rc.local, etc.) The general idea is to have standard frame (rc.engine + rc.conf knobs) of things that users would not want to change at all ever (meaning, not to block them to do so "because", but because there's no point), while leaving anything not falling into that category in hooks. From rejmerge point of view - rc.hooks/** + rc.conf would be rejected (though personally, I'd - by default - add all rc stuff)
One thing I do not understand is why you move the code to mount the fusectl filesystem to the init system.
I was actually wondering myself (same thing about configfs or debugfs) - leave in udev (if applicable), leave in rc.engine, or perhaps in rc.hooks. I settled for "engine", as it's just simple virtual filesystem one wants mounted once and forget it's there. It will survive along runtime changes, and until the very reboot. And there's rc.conf knob too. So from all the choices, it seemed the most optimal one (I'd guess similar reasoning was on systemd side, though I don't follow its mailing list). Kind of similar to shm / pts / sys / run (soon) / dev / proc and so on, which are mounted once with desirable options and not touched again.
IMO this should be done at the time the kernel module is loaded. Have you seen the rule I've added in udev 174? Adding the rule to the port opt/fuse might be another option as well.
Btw, current version of my rc-ng repo (did few minor shuffles, so it's forced non-ff) have latest commit of how udev can look with those scripts.
Btw, shouldn't we try to add application specific stuff like the one for lvm and mdadm via the corresponding port, a kind of run-control directory with short scripts added by the packages comes to my mind?
I'd rather left that to users. More complex configurations can vary quite a lot, their parts can be stuffed in different places - depending on one's needs. Existing hooks are just an example/headstart.
P.S. unfortunately my time is still very limited at the moment, but I will try to do a first test of rc-ng next week.
Make sure to fetch the last version (and move mkfifo/mktemp/setsid to /bin - if you mount /usr) - I have few small things in mind to add. At some point I'll push rc-ng-run as well, with all the necessary changes around. udevd already complains loudly about lack of /run, and mtab symlink is pretty nice to have. P.S. I started updating pkgmk as well, I can't live without native git support, and few lesser things (such as local directories) ... for a start ;) Maybe add regular crux@ to CC as well ?