Hey all,
Michael, thanks a lot, your work is too appreciated.
This mail, due to my poor English and little time nowadays, probably not
cover everything I think, but I've long wanted to send it and should not
delay it anymore, so sorry if there is anything that is not well
explained or incomplete.
I'll try to argue my POV with advantages/disadvantages as better as
possible, and if necessary bringing new ideas and proposals.
The first thing that comes to my mind is the complexity of the new
solution for system initialization files that you have proposed.
I think that it's much more complicated than our current one, but I'm
always open to new ideas and improvements.
I supposse that you worked in this stuff due to solve/optimize issues
you found, maybe with lvm/mdadm, but I'm not 100% sure that I got the
whole idea, so please correct me if I'm wrong somewhere. Also I noted
that ArchLinux has a similar implementation (1) that could be reviewed.
*** (about hooks) ***
Basically I like user configurable hooks as alternative to rc.local (or
complement), and not as an imposition (some hooks are empty files).
I'd like to have a minimal rc port, and let people to use as hooks as
need it. This would make for rc* init scripts to load only the hooks
that were selected by users to use.
Personally, I have years managing CRUX systems and I've never needed
anything extra apart from a couple of lines in rc.local, as is the case
with rc.local/rc.local.conf in OpenBSD systems.
Accordingly, I think we might have enough to accommodate all the hooks
in a single directory, I like: /etc/rc.conf.d/hooks.
Another disadvantage (IMHO) with rc-hooks could be inherited and overlap
the config that has established the user. Which brings us back to run
rejmerge for all rc-hooks (around 20 hooks maybe?) after each update rc
port. That reinforces the idea of having a small rc port.
In addition I'd like to review the naming convention. I prefer the one
used by ArchLinux (2) which could be housed in the same directory (maybe
/etc/rc.conf.d/hooks/) and not lose its meaning:
your schema => my proposal
---------------------------
multi/early => multi_start
sysinit/early => sysinit_start
sysinit/late => sysinit_end
sysinit/udev-runner1 => sysinit_udev-runner1
sysinit/udev-runner2 => sysinit_udev-runner2
...
Also I found that there are 2 hooks (sysinit/early and
sysinit/pre-trigger1) where the second hook is executed immediately
after the first one which is meaningless, so in this case both hooks
could be merged into one:
--- /etc/rc.sysinit ---
rc_hook sysinit/early
rc_hook sysinit/pre-trigger1
si_udev
--- endof /etc/rc.sysinit ---
*** (about functions) ***
I like most functions you added and/or implemented, new tools from
util-linux-ng (like findmnt, etc.) and also new bash syntax and
features. Good work!!
But why not have all functions in only one file? (maybe
/etc/rc.conf.d/functions) So there are about only 30 functions.
$ grep 'function .*()' /etc/rc.engine/* | wc -l
30
IMHO code refactoring makes sense when the same function is used from
multiple places. If, for example, rc.engine/multi functions are only
used from rc.multi script the it makes no sense to separate it into a
single file, so the effect would be the same like include only those
functions in rc.multi script since no more rc scripts required them.
Also I would like to adopt and/or discuss a more consistent naming
convention for functions.
your schema
-----------
rc.engine/all:function __rc_spawner() {
rc.engine/all:function rc_srv_start() {
rc.engine/lib:function start_kmsg_log() {
rc.engine/sysinit:function __si_console() {
rc.engine/sysinit:function __si_seed() {
rc.engine/sysinit:function si_std() {
my proposal
-----------
rc_spawner(), rc_srv_start(), kmsg_log_start(), sysinit_console(),
sysinit_seed(), sysinit_std(), ...
In addition it would be fine to have some functions like
start_service(), stop_service() that could be used by services/daemons
in /etc/rc.d/* like sshd or others.
For example, stop_service() basically could do:
stop_service() {
local SUCCESS=0
local SERVICE=$1
local PIDFILE=/var/run/$SERVICE.pid
#[ $VERBOSE -eq 1 ] && echo -n "Stopping $SERVICE:\t"
if [ -f /var/run/$SERVICE.pid ]; then
kill $(< /var/run/$SERVICE.pid)
if [ $? -ne 0 ]; then
SUCCESS=1
rm -f /var/run/$SERVICE.pid
fi
else
killall -q /usr/sbin/$SERVICE # we could use another argument like
$BINFILE instead of $SERVICE
[ $? -ne 0 ] && SUCCESS=1
fi
#if [ $VERBOSE -eq 1 ]; then
# if [ $SUCCESS -eq 1 ]; then
# echo "[OK]"
# else
# echo "[FAILED]"
# fi
#fi
}
-- note that this is only an idea and of course it could be written
better, have global vars like $VERBOSE, etc.
*** (lvm/mdadm) ***
For what I see, /etc/rc.hooks/sysinit/udev-runner1 is the place where
lvm/mdadm lives.
Can't be possible to move this stuff to their respective daemons in
/etc/rc.d/lvm and /etc/rc.d/mdadm? It could be a clean way and better
for boxes where no lvm/mdadm config is required and/or used.
*** (miscelaneous) ***
Why you added -8 --noclear to inittab?
-- c1:2:respawn:/sbin/agetty 38400 tty1 linux
++ c1:2:respawn:/sbin/agetty 38400 -8 --noclear tty1 linux
IMHO, I would leave it as is and give users freedom to change or not.
Why not move rc.engine/tlkd to functions as tlkd(), or even to
/etc/rc.d/tlkd as a complete daemon service?
I'm sure I missed something but at least I hope I have expressed my
ideas and opinions.
Best regards,
(1)
https://wiki.archlinux.org/index.php/Arch_Boot_Process#.2Fetc.2Frc.sysinit
(2) https://wiki.archlinux.org/index.php/Arch_Boot_Process#Custom_hooks
--
Jose V Beneyto | http://sepen.it.cx/
_______________________________________________
crux-devel mailing list
crux-devel@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux-devel
