Re: Upstart on kFreeBSD? [was: The future of the boot system in Debian]

View: New views
3 Messages — Rating Filter:   Alert me  

Re: Upstart on kFreeBSD? [was: The future of the boot system in Debian]

by Alan Jenkins-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 9/5/09, Petter Reinholdtsen <pere@...> 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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...


Re: Upstart on kFreeBSD? [was: The future of the boot system in Debian]

by Guillem Jover :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi!

On Sat, 2009-11-07 at 14:00:23 +0000, Alan Jenkins wrote:
> On 9/5/09, Petter Reinholdtsen <pere@...> wrote:
> > 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.

> 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.

There's several others (taken from this thread [0]):

 * SIGPWR
 * inotify
 * waitid()
 * epoll, eventfd, signalfd, timerfd
 * ptrace
 * netlink proc connector
 * netlink udev interface

Check Scott's [1] and Petr's [2] mails on that thread for more details.

[0] <http://lists.debian.org/debian-bsd/2009/07/msg00117.html>
[1] <http://lists.debian.org/debian-bsd/2009/07/msg00122.html>
[2] <http://lists.debian.org/debian-bsd/2009/07/msg00120.html>

> 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.

The biggest issue I see is that someone will have to step up and
become “upstream” for the non-Linux ports, given Scott's position.
I'm not sure how he'd expect those to get released, if as outright
forks or something else, that'd need to be discussed with him. It will
also need copyright assignments [3] for the code that might need to be
merged back.

[3] <http://upstart.ubuntu.com/wiki/CopyrightAssignment>

> Does this make any sense?  Is anyone already working on running
> upstart scripts on non-linux architectures?

It was brought up in the debian-bsd list, but I don't know of any one
working on it.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...


Re: Upstart on kFreeBSD? [was: The future of the boot system in Debian]

by Alan Jenkins-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/7/09, Guillem Jover <guillem@...> wrote:

> Hi!
>
> On Sat, 2009-11-07 at 14:00:23 +0000, Alan Jenkins wrote:
>> On 9/5/09, Petter Reinholdtsen <pere@...> wrote:
>> > 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.
>
>> 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.
>
> There's several others (taken from this thread [0]):
>
>  * SIGPWR
>  * inotify
>  * waitid()
>  * epoll, eventfd, signalfd, timerfd
>  * ptrace
>  * netlink proc connector
>  * netlink udev interface
>
> Check Scott's [1] and Petr's [2] mails on that thread for more details.
>
> [0] <http://lists.debian.org/debian-bsd/2009/07/msg00117.html>
> [1] <http://lists.debian.org/debian-bsd/2009/07/msg00122.html>
> [2] <http://lists.debian.org/debian-bsd/2009/07/msg00120.html>
>
>> 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.
>
> The biggest issue I see is that someone will have to step up and
> become “upstream” for the non-Linux ports, given Scott's position.
> I'm not sure how he'd expect those to get released, if as outright
> forks or something else, that'd need to be discussed with him. It will
> also need copyright assignments [3] for the code that might need to be
> merged back.
>
> [3] <http://upstart.ubuntu.com/wiki/CopyrightAssignment>
>
>> Does this make any sense?  Is anyone already working on running
>> upstart scripts on non-linux architectures?
>
> It was brought up in the debian-bsd list, but I don't know of any one
> working on it.
>
> regards,
> guillem

Thanks!
Alan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...