On 9/5/09, Petter Reinholdtsen <p...@hungry.com> wrote: > > The future of the boot system in Debian > ======================================= ... body omitted; see <http://lwn.net/Articles/351013/> ... > Petter Reinholdtsen, Kel Modderman, Armin Berres >
Thanks for the informative announcement. I am curious about this specific proposal - > change the init.d script > handling to treat upstart jobs as init.d scripts, to provide an > alternative for architectures lacking upstart support I read this as a euphemism for non-linux architectures such as kFreeBSD. But I don't understand how this would be done. I don't believe there is a bijection between upstart scripts and traditional System V init scripts. To take one example, an essential feature is to discover the PID for each daemon, so that it can be stopped if requested. Upstart automatically determines daemon pids, with directives such as "expect fork" (which uses ptrace()). Traditional init scripts use different mechanisms, usually a pidfile. It seems that maintaining both alternatives would require either a hefty abstraction layer or a substantial amount of duplication. An alternative would be to make upstart more portable. At the moment the only obvious technical problem is the use of ptrace(), but I don't see this as insurmountable. I think the biggest problem would be to persuade upstream. I'm prepared to work on the code... if it's really feasible, it shouldn't take too long. What I can't do is make a solid case to upstream by myself. It would really need agreement from the debian upstart maintainers that this is their preferred way forward, along with a commitment that Debian will help resolve any portability issues which arise in future versions of upstart. Does this make any sense? Is anyone already working on running upstart scripts on non-linux architectures? Regards Alan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
