Quoth Bill Nottingham: > Since I've been asked in various places what we're planning to > do with upstart now that Fedora 9 has shipped, I figured I'd > lay out the basic plan. > > To do any large-scale conversion of SysV init scripts to upstart, > we need some features that are not in the current (0.3.9) version. > Hence, the first thing is to get upstart 0.5 ready for inclusion. > For example, we need support for the following: > > - Depending on multiple events > > I.e., have something start only if two separate events have > both completed successfully. For a disturbing example of how > we work around this now, read /etc/event.d/serial. > > - Ability to enable/disable events in a way other than removing > the file > > (The reasoning for this should be fairly obvious) > > - Ability to group events into sets, or profiles > > This allows us to handle the sort of behaviors that runlevels are > used for sanely. > > - Ability to easily have upstart events depend on SysV scripts, and > vice-versa > > If one of a SysV scripts' dependencies is started by upstart, we > need to be able to still handle that sanely. > > This isn't meant to be an exhaustive list, but it is meant to > illustrate why we can't just move services right now. > > Once we get upstart 0.5 in, we can then look at potentially moving > some subset of things that are now handled elsewhere to upstart. > Examples would be: > > - Always-on services such as dbus, syslog, and audit > - Reworking things like netfs to be more sane, when > it comes to networks coming and going, network block devices being > attached and detached, and so on > - Potentially splitting some of rc.sysinit into multiple events. > Not sure this buys us much, as right now the flow is *extremely* > sequential (start_udev -> fsck -> remount r/w -> clean out /tmp) > - Coming up with a sane network notification strategy > Right now, we have events kicked off on network changes: > - via netreport > - via NetworkManagerDispatcher > - conceivably, via upstart (after all, spawning commands/etc based > on events is its raison d'etre) > Having a coherent strategy for apps to only need to worry about > dropping things in one place would make sense. > - (possibly) having either upstart 'handle' sysv services more natively > or wrap tools such as chkconfig, /sbin/service so they handle both > SysV and upstart. > > All clear as mud? > > Bill Thanks for keeping us informed of the current state of (upstart) affairs. -- Conrad Meyer <konrad@xxxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
