The only useful things in the excerpt you quoted are:
- the initial setsid() (which can be achieved via a call to
s6-setsid in the stage 1 script)
- setlogin("root"), which is FreeBSD-specific
- the devfs test, if you want things to work even when /dev
is not mounted yet. In which case you also, I guess, have to
reopen /dev/console; but that could just as well be done in
the stage 1 script, as s6-linux-init does on Linux.
Original init also
handles failures, parses bootloader defined variables and invocation parameters,
does single user mode and lot more, So this is really just dumb hack.
I don't think it's a dumb hack. I find it very interesting to understand
exactly what an init is doing; and you are actually pioneering a potential
future s6-freebsd-init package. :)
FreeBSD has it's own rc.d framework and I am still learning how it works.
Unfortunately some tasks need to be done before supervisor spins-up
Why ? Does the rc system need specific hooks with the FreeBSD init
program ?
Because if it doesn't, then it's perfectly ok to get s6-svscan running
first, and do *all* your rc stuff in stage 2. There's no reason why it
can't work.
With runit, all your one-time initialization has to be done in stage 1,
because stage 2 is only about the long-running processes. But with s6,
if you are following the s6-linux-init model, then you can actually do
the one-time initialization in stage 2, when s6-svscan is already running.
I see so this is clang issue. Well I have yet to learn ktrace, so I am putting
this on hold until I get some time to study it. I hope I will get some chance to
get these dumps correctly later this week.
I'll try some experiments there too, thanks for the report.
Hope to hear from you soon !
--
Laurent
