On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson <cjwat...@debian.org>
wrote:
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
My belief, and again I welcome concrete reasons why I'm not
correct, is
that adopting upstart poses a similar risk for the Hurd port as
adopting
systemd, and I care just as much about the Hurd port as kFreeBSD.
And
while kFreeBSD is in better shape due to the already-begun upstart
port,
there are still significant porting challenges in the way of
maintaining
feature parity in the kFreeBSD port at the level that it has today.
Many
of those challenges are going to remain regardless of which init
system we
pick.
I haven't looked at this in much detail, and I suspect Dimitri hasn't
yet although IIRC he did express some interest in doing so. But I
haven't seen anyone else try to outline the scope of a port, so let me
try to do so for the sake of general understanding. As far as I know,
the hardest parts would be inotify, ptrace, and prctl
(PR_SET_CHILD_SUBREAPER).
inotify is used to notice changes to configuration files. This is
certainly helpful for users, but it isn't critical as "initctl
reload-configuration" works without it. We could probably do without
this with the aid of a dpkg trigger.
inotify use can easily be ported to kqueue within Upstart, or
libinotify-kqueue can be used.
ptrace is used for "expect fork" and "expect daemon"; as I indicated
in
another post, I think it would be preferable to avoid these in Debian
and quite possibly to compile them out. (This would mean we wouldn't
be
able to translate Ubuntu jobs quite as directly, and a number of
important jobs would definitely need to be changed, but the conversion
isn't usually particularly difficult.)
If we are able to settle on a readiness protocol and fully (or almost
fully) implement it, then ptrace will become irrelevant. I am sure that
if upstream is in agreement on the proto, then Ubuntu and Debian can
collaborate to update the jobs (and daemons) for their next releases.
prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification
work
properly when Upstart is supervising a user session. This isn't a
required feature and could easily be compiled out until suitable
kernel
support is available (this actually seems like the sort of thing that
could be done in the Hurd without too much difficulty, but I haven't
looked into it). If absent, it might well impede the ability to do an
advanced desktop port, but it wouldn't get in the way of porting the
bulk of services.
Unity, likely the only desktop environment using Upstart as a session
init, is not in Debian. The sacrifice of this functionality on
non-linux systems is perfectly acceptable.
There might also be odds and ends around the details of wait status
handling.
Two things come to mind: use of epoll in upstart-socket-bridge, and no
abstract namespace sockets.
So, I'll certainly concede that I haven't actually tried this, but
from
what I know of Upstart/libnih's system dependencies, I think that the
Hurd could be accommodated with at worst possibly some loss of
non-critical features.
I want to mention again something that you'd dismissed as possibly
a joke
earlier, but which I was actually serious about: I think a world in
which
we use systemd on Linux and upstart on non-Linux ports, should
upstart
prove much more portable, actually makes sense. As I said in my
other
writeup, I believe the systemd feature advantage is sufficient to
choose
systemd in isolation, without the other issues discussed. I also
believe
that maintaining a systemd unit plus an upstart configuration is,
modulo
testing (which I realize is a huge issue), much easier than
maintaining a
single sysvinit script.
I wouldn't discard this option out of hand, but I think it would need
significant tool support to be practical (e.g. heuristic generation of
Upstart job files from systemd units), unless we expect all service
maintainers to have kFreeBSD/Hurd VMs lying around. Keeping the
sysvinit scripts and using Upstart as the init daemon is another
possibility, and at least in that case the sysvinit scripts are
probably
still lying around. We don't even necessarily have to choose between
those up-front.
Cheers,
Cameron Norman
