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 ?
_______________________________________________
crux-devel mailing list
[email protected]
http://lists.crux.nu/mailman/listinfo/crux-devel
