On init in Debian

classic Classic list List threaded Threaded
226 messages Options
1234 ... 12
Reply | Threaded
Open this post in threaded view
|

On init in Debian

Lars Wirzenius-5
There is a lot of feelings and temper involved in the current discussion
of init implementations in Debian. I'd like to try to de-escalate by
summarizing things in as objective and non-confrontational manner as I can.

* sysvinit is mostly working for everyone, but it has problems, in part
  caused by changes in the kernel over the years. See [1] by Petter.
  It's not even primarily about boot speed, but about reliability,
  especially in the early boot.
* It's also the case that our init.d scripts are full of repetitive code,
  often subtly different, and similar bugs happen independently in many
  places. If we stay with sysvinit, we need to fix this.
* Event based init systems attempt to provide other things too,
  including faster boot speed, and an overall simpler, faster, leaner,
  and more reliable system.
* The two main event based contenders are upstart and sysvinit. Both are
  written for Linux, and rely on various Linux specific kernel features.
  They have some technical and other differences, and have upstream
  developers who can be considered controversial in various ways by
  various people in Debian. However, both are, of course, free software,
  and both should work acceptably well as an init in the Linux version of
  Debian.
* We can choose to stay with sysvinit, but then we'll need to start
  developing it to be more suitable for modern Linux.
* We can choose upstart or sysvinit for Linux, but then we need to deal
  with their current incompatibility with the Hurd and kFreeBSD ports of
  Debian.
* It might be workable to have most services use init.d files even in the
  future, and then use sysvinit on the non-Linux ports. However, this
  removes much of the benefit of the new inits on Linux.
* We could require every package that provides a service that needs to be
  started by init to support both sysvinit and upstart or systemd. However,
  given the realities of Debian development, this would probably mean
  that one of them would be badly tested, and therefore likely to be buggy.
* We could try to have a tool to automatically convert an upstart or systemd
  service configuration into a sysvinit init.d script. I have no idea if that
  is really feasible, but if it worked for most packages, we could probably
  live with the others requiring some manual work.
* We can decide to drop those ports. They're not used a lot, but they do
  have a loyal and enthusiastic fan base, even if small. Dropping them is
  not an easy decision. Keeping them is also not easy, if it means
  compromising the quality of the Linux version of Debian. This is probably
  what causes most of the emotional distress.
* We can attempt to port upstart or sysvinit to the Hurd and kFreeBSD,
  either by changing the userland code or the kernel code. This may or may
  not be a large undertaking; I don't know if anyone's actually attempted
  it yet. (As a side note, if Canonical wants to stick with upstart, it'd
  be in their interest to have Debian use it too, I think, and perhaps they
  could do the Hurd and kFreeBSD porting?)
 
Did I miss anything of substance?

I don't know what should happen next, except someone should take leadership
on this issue and find a rough consensus on what we as a project want to do.
The usual way of that to happen is for someone to grab a keyboard and start
writing actual code, as opposed to e-mails. Do-ocracy ftw.

[1] http://lists.debian.org/debian-devel/2012/02/msg01043.html

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Lars Wirzenius-5
Ergh, I got sysvinit and systemd mixed in some places. We should
ban from Debian more than one program starting with the same letter.
Thanks, Dave, for pointing this out to me quickly.

On Fri, Mar 16, 2012 at 10:14:53AM +0000, Lars Wirzenius wrote:
> * The two main event based contenders are upstart and sysvinit. Both are

s/sysvinit/systemd/ in the above line.

> * We can choose upstart or sysvinit for Linux, but then we need to deal

s/sysvinit/systemd/ in the above line.

> * We can attempt to port upstart or sysvinit to the Hurd and kFreeBSD,

s/sysvinit/systemd/ in the above line.

Sorry about any confusion.

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Marco d'Itri
In reply to this post by Lars Wirzenius-5
On Mar 16, Lars Wirzenius <[hidden email]> wrote:

>   They have some technical and other differences, and have upstream
>   developers who can be considered controversial in various ways by
>   various people in Debian.
How are the upstart developers controversial? Did I miss something?


>   it yet. (As a side note, if Canonical wants to stick with upstart, it'd
>   be in their interest to have Debian use it too, I think, and perhaps they
>   could do the Hurd and kFreeBSD porting?)
A point which I find interesting is that Ubuntu, our most important
derivative distribution, is committed to upstart so by adopting it we
could benefit from synergies.

> The usual way of that to happen is for someone to grab a keyboard and start
> writing actual code, as opposed to e-mails. Do-ocracy ftw.
We already have the code for Linux systems, we even have two different
and competing implementations.
The problem is the lack of code for the toy ports, and by now I think it
is clear that nobody has plans to write it.

--
ciao,
Marco

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Vincent Danjean-3
In reply to this post by Lars Wirzenius-5
Le 16/03/2012 11:14, Lars Wirzenius a écrit :
> * We could try to have a tool to automatically convert an upstart or systemd
>   service configuration into a sysvinit init.d script. I have no idea if that
>   is really feasible, but if it worked for most packages, we could probably
>   live with the others requiring some manual work.

* We could try to define a file format that allow a conversion (by a
  separate specific tool or at runtime) to various init systems.
  This would avoid to be blocked by the syntax/features of one "source"
  init system.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4F634223.60604@...

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Josselin Mouette
In reply to this post by Marco d'Itri
Le vendredi 16 mars 2012 à 14:26 +0100, Marco d'Itri a écrit :
> How are the upstart developers controversial? Did I miss something?

Canonical contributor agreement.

> The problem is the lack of code for the toy ports, and by now I think it
> is clear that nobody has plans to write it.

Fully agreed.

--
 .''`.      Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/1331906066.14697.102.camel@pi0307572

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Marc Haber-3
In reply to this post by Marco d'Itri
On Fri, 16 Mar 2012 14:26:35 +0100, [hidden email] (Marco d'Itri) wrote:
>The problem is the lack of code for the toy ports,

It would really be nice if you could at least try to not plant
unnecessary attacks against people who have a working style different
from yours in every second message you write.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/E1S8YXt-0001b2-AX@...

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Samuel Thibault-8
In reply to this post by Vincent Danjean-3
Vincent Danjean, le Fri 16 Mar 2012 14:37:39 +0100, a écrit :

> Le 16/03/2012 11:14, Lars Wirzenius a écrit :
> > * We could try to have a tool to automatically convert an upstart or systemd
> >   service configuration into a sysvinit init.d script. I have no idea if that
> >   is really feasible, but if it worked for most packages, we could probably
> >   live with the others requiring some manual work.
>
> * We could try to define a file format that allow a conversion (by a
>   separate specific tool or at runtime) to various init systems.
>   This would avoid to be blocked by the syntax/features of one "source"
>   init system.

I'm a bit afraid of http://xkcd.com/927/

Samuel


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120316164035.GO4442@...

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Marco d'Itri
In reply to this post by Marc Haber-3
On Mar 16, Marc Haber <[hidden email]> wrote:

> On Fri, 16 Mar 2012 14:26:35 +0100, [hidden email] (Marco d'Itri) wrote:
> >The problem is the lack of code for the toy ports,
> It would really be nice if you could at least try to not plant
> unnecessary attacks against people who have a working style different
> from yours in every second message you write.
What attack? Toys are not evil, I like toys.
But an OS developed by 10 people for maybe 100 people is still a toy.

--
ciao,
Marco

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Marc Haber-3
On Fri, 16 Mar 2012 18:02:16 +0100, [hidden email] (Marco d'Itri) wrote:
>On Mar 16, Marc Haber <[hidden email]> wrote:
>> On Fri, 16 Mar 2012 14:26:35 +0100, [hidden email] (Marco d'Itri) wrote:
>> >The problem is the lack of code for the toy ports,
>> It would really be nice if you could at least try to not plant
>> unnecessary attacks against people who have a working style different
>> from yours in every second message you write.
>What attack? Toys are not evil, I like toys.

I am surely not the only one who took your mail cited above as
intentionally derogatory. But that might be cultural differences
and/or language challenges.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/E1S8anK-0000ak-3C@...

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Philip Hands
In reply to this post by Vincent Danjean-3
On Fri, 16 Mar 2012 14:37:39 +0100, Vincent Danjean <[hidden email]> wrote:

> Le 16/03/2012 11:14, Lars Wirzenius a écrit :
> > * We could try to have a tool to automatically convert an upstart or systemd
> >   service configuration into a sysvinit init.d script. I have no idea if that
> >   is really feasible, but if it worked for most packages, we could probably
> >   live with the others requiring some manual work.
>
> * We could try to define a file format that allow a conversion (by a
>   separate specific tool or at runtime) to various init systems.
>   This would avoid to be blocked by the syntax/features of one "source"
>   init system.
This was mentioned in the thread (I forget by whom) and strikes me as
the only viable strategy, in that this is the only way that the various
factions can all collaborate on making a workable solution, rather than
fighting for theirs to be The One True Init.

It also has the added bonus of allowing a future transition to an as yet
undreamt of opto-quantum-nano-init without having to reiterate all this
grizzling.

If we could get buy-in from other distros and other *nix variants, we
might have some chance of solving this problem for them as well, once
we've done the proof of concept -- although I'd presume that NIH would
probably stop it getting anywhere with RedHat or SUSE, unfortunately.

Cheers, Phil.
--
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Marco d'Itri
In reply to this post by Vincent Danjean-3
On Mar 16, Vincent Danjean <[hidden email]> wrote:

> * We could try to define a file format that allow a conversion (by a
>   separate specific tool or at runtime) to various init systems.
>   This would avoid to be blocked by the syntax/features of one "source"
>   init system.
I doubt that this is possible except for the most trivial cases (which
are not interesting), because the three init systems do not have the
same features and they have different semantics.

--
ciao,
Marco

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Alexander Wirt-2
In reply to this post by Marco d'Itri
Marco d'Itri schrieb am Friday, den 16. March 2012:

> On Mar 16, Marc Haber <[hidden email]> wrote:
>
> > On Fri, 16 Mar 2012 14:26:35 +0100, [hidden email] (Marco d'Itri) wrote:
> > >The problem is the lack of code for the toy ports,
> > It would really be nice if you could at least try to not plant
> > unnecessary attacks against people who have a working style different
> > from yours in every second message you write.
> What attack? Toys are not evil, I like toys.
> But an OS developed by 10 people for maybe 100 people is still a toy.
Yeah, like Linux too not so long ago. With people like you we would still
have to use Windows.

Alex


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120316174946.GA26230@...

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Allison Randal-6
In reply to this post by Josselin Mouette
On 03/16/2012 06:54 AM, Josselin Mouette wrote:
> Le vendredi 16 mars 2012 à 14:26 +0100, Marco d'Itri a écrit :
>> How are the upstart developers controversial? Did I miss something?
>
> Canonical contributor agreement.

Hypothetically, if this went away, would it have a substantial impact on
the decision? [NOTE: I don't work for Canonical, and don't have a magic
wand to poof it away.]

I'm curious what the discussion would look like if the only obstacles
were technical. And how difficult those technical obstacles would be to
solve.

Allison


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4F637F5C.2090104@...

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Russ Allbery-2
In reply to this post by Lars Wirzenius-5
Lars Wirzenius <[hidden email]> writes:

> I don't know what should happen next, except someone should take
> leadership on this issue and find a rough consensus on what we as a
> project want to do.  The usual way of that to happen is for someone to
> grab a keyboard and start writing actual code, as opposed to
> e-mails. Do-ocracy ftw.

I believe we should finalize the Policy update to allow packages to start
including optional upstart scripts (#591791, which needs more seconds),
write a similar Policy update for systemd, and then get some practical
experience.

That doesn't resolve the whole problem, but it does let people start doing
things instead of just talking about it and may uncover interesting data.
And allowing packages to include parallel upstart configuration with init
scripts that defer to upstart when it's available has the separate
advantage of immediately making life easier for packagers who want to
maintain the same package on both Debian and Ubuntu.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87haxocrma.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Andreas Metzler
In reply to this post by Philip Hands
Philip Hands <[hidden email]> wrote:
> On Fri, 16 Mar 2012 14:37:39 +0100, Vincent Danjean <[hidden email]> wrote:
[...]
>> * We could try to define a file format that allow a conversion (by a
>>   separate specific tool or at runtime) to various init systems.
>>   This would avoid to be blocked by the syntax/features of one "source"
>>   init system.

> This was mentioned in the thread (I forget by whom) and strikes me as
> the only viable strategy, in that this is the only way that the various
> factions can all collaborate on making a workable solution, rather than
> fighting for theirs to be The One True Init.
[...]

I am not sure this actually is a big improvement, we might end up with

* either being limited to the common featureset
* or doing something like
#ifdef systemd
....
elseif upstart
...
which is almost as bad as having to ship both init-scripts and systemd
configuration file.

cu andreas



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/lgfc39-9ch.ln1@...

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Michael Biebl-3
In reply to this post by Russ Allbery-2
On 16.03.2012 19:45, Russ Allbery wrote:

> Lars Wirzenius <[hidden email]> writes:
>
>> I don't know what should happen next, except someone should take
>> leadership on this issue and find a rough consensus on what we as a
>> project want to do.  The usual way of that to happen is for someone to
>> grab a keyboard and start writing actual code, as opposed to
>> e-mails. Do-ocracy ftw.
>
> I believe we should finalize the Policy update to allow packages to start
> including optional upstart scripts (#591791, which needs more seconds),
> write a similar Policy update for systemd, and then get some practical
> experience.
>
> That doesn't resolve the whole problem, but it does let people start doing
> things instead of just talking about it and may uncover interesting data.
Just for the record: We already have 30+ packages in Debian shipping
native systemd unit files.
For a standard Debian (desktop) installation there are not that many
sysv init scripts left, that need to be run.
And the number of native systemd services is continually growing, thanks
to systemd upstream pushing the mantra of including those files directly
upstream.

I'm mainly interested in systemd (as Tollef) and we are already working
hard to make the integration and transition as smooth as possible.

The lack of participation on all these threads doesn't mean there isn't
anything happening on the systemd side, on the contrary.
Personally, I sadly noticed that all these previous discussions lead to
nothing, so I just tried to keep out of it.

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


signature.asc (918 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Russ Allbery-2
Michael Biebl <[hidden email]> writes:

> Just for the record: We already have 30+ packages in Debian shipping
> native systemd unit files.  For a standard Debian (desktop) installation
> there are not that many sysv init scripts left, that need to be run.
> And the number of native systemd services is continually growing, thanks
> to systemd upstream pushing the mantra of including those files directly
> upstream.

> I'm mainly interested in systemd (as Tollef) and we are already working
> hard to make the integration and transition as smooth as possible.

Could you please write up how to do that as a Policy amendment similar to
what Steve did for upstart, addressing similar issues?  I'm happy to
review and second.

> Personally, I sadly noticed that all these previous discussions lead to
> nothing, so I just tried to keep out of it.

I think that's a fine decision.  I'm interested in getting the information
into Policy so that I know what to do to support upstart and systemd in my
own packages.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/8762e4ib6f.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Philip Hands
In reply to this post by Andreas Metzler
On Fri, 16 Mar 2012 20:05:25 +0100, Andreas Metzler <[hidden email]> wrote:

> Philip Hands <[hidden email]> wrote:
> > On Fri, 16 Mar 2012 14:37:39 +0100, Vincent Danjean <[hidden email]> wrote:
> [...]
> >> * We could try to define a file format that allow a conversion (by a
> >>   separate specific tool or at runtime) to various init systems.
> >>   This would avoid to be blocked by the syntax/features of one "source"
> >>   init system.
>
> > This was mentioned in the thread (I forget by whom) and strikes me as
> > the only viable strategy, in that this is the only way that the various
> > factions can all collaborate on making a workable solution, rather than
> > fighting for theirs to be The One True Init.
> [...]
>
> I am not sure this actually is a big improvement, we might end up with
>
> * either being limited to the common featureset
> * or doing something like
> #ifdef systemd
> ....
> elseif upstart
> ...
> which is almost as bad as having to ship both init-scripts and systemd
> configuration file.
If we were going to end up with anything like that, then it would be no
improvement at all, and would not be worth wasting any effort on.

I was presuming (perhaps wrongly) that it would be possible to come up
with a high level specification of what a daemon provides, what it needs
to happen in order to run, what needs to be done to provoke it to reread
its settings, how one runs it in the foreground, and in the background
(either of which might be missing) etc. etc. etc

And then, given that lot, write a generic init.d script that can take
that as input and do something useful with it, but likewise, process it
into appropriate configs for both systemd and upstart.

Of course, I don't know enough about either systemd or upstart to know
how feasible such an approach might be, but if it is feasible it would
almost certainly eliminate some of the repeated bugs in sysinit at least,
and perhaps be helpful in the same way for the other two.

On the other hand, the xkcd cartoon is depressingly true, so perhaps we
should forget that idea -- I was rather hoping that it doesn't quite
apply here though, since we'd not be trying to write yet another init,
but just describe the configuration data needed by all init type things.

Cheers, Phil.
--
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Gunnar Wolf
In reply to this post by Vincent Danjean-3
Vincent Danjean dijo [Fri, Mar 16, 2012 at 02:37:39PM +0100]:
> * We could try to define a file format that allow a conversion (by a
>   separate specific tool or at runtime) to various init systems.
>   This would avoid to be blocked by the syntax/features of one "source"
>   init system.

There is even (old, yes, but still usable I'd venture) work on this
line, by  Joachim Breitner:

    http://packages.qa.debian.org/m/metainit.html
    http://wiki.debian.org/MetaInit

Metainit has not been touched for four years already, but that was
precisely its initial position.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120316235029.GB26502@...

Reply | Threaded
Open this post in threaded view
|

Re: On init in Debian

Philip Ashmore
In reply to this post by Philip Hands
On 16/03/12 21:44, Philip Hands wrote:

> On Fri, 16 Mar 2012 20:05:25 +0100, Andreas Metzler<[hidden email]>  wrote:
>> Philip Hands<[hidden email]>  wrote:
>>> On Fri, 16 Mar 2012 14:37:39 +0100, Vincent Danjean<[hidden email]>  wrote:
>> [...]
>>>> * We could try to define a file format that allow a conversion (by a
>>>>    separate specific tool or at runtime) to various init systems.
>>>>    This would avoid to be blocked by the syntax/features of one "source"
>>>>    init system.
>>> This was mentioned in the thread (I forget by whom) and strikes me as
>>> the only viable strategy, in that this is the only way that the various
>>> factions can all collaborate on making a workable solution, rather than
>>> fighting for theirs to be The One True Init.
>> [...]
>>
>> I am not sure this actually is a big improvement, we might end up with
>>
>> * either being limited to the common featureset
>> * or doing something like
>> #ifdef systemd
>> ....
>> elseif upstart
>> ...
>> which is almost as bad as having to ship both init-scripts and systemd
>> configuration file.
> If we were going to end up with anything like that, then it would be no
> improvement at all, and would not be worth wasting any effort on.
>
> I was presuming (perhaps wrongly) that it would be possible to come up
> with a high level specification of what a daemon provides, what it needs
> to happen in order to run, what needs to be done to provoke it to reread
> its settings, how one runs it in the foreground, and in the background
> (either of which might be missing) etc. etc. etc
>
> And then, given that lot, write a generic init.d script that can take
> that as input and do something useful with it, but likewise, process it
> into appropriate configs for both systemd and upstart.
>
> Of course, I don't know enough about either systemd or upstart to know
> how feasible such an approach might be, but if it is feasible it would
> almost certainly eliminate some of the repeated bugs in sysinit at least,
> and perhaps be helpful in the same way for the other two.
>
> On the other hand, the xkcd cartoon is depressingly true, so perhaps we
> should forget that idea -- I was rather hoping that it doesn't quite
> apply here though, since we'd not be trying to write yet another init,
> but just describe the configuration data needed by all init type things.
>
> Cheers, Phil.
I'm writing a system that can accept the following:

     program
     ( name("hello-world")
     , contents
         ( sys-include("stdio.h")
         , function
             ( name("main")
             , returns("int")
             , parameters
                 ( parameter(name("argc"), type("int"))
                 , parameter(name("argv"), type(array(pointer("char"))))
                 )
             , body
                 ( call("printf", "Hello, world!\n")
                 , return(0)
                 )
             )
         )
     )

and parse it into a binary form.

With this I can use a c/c++ generator program to produce

     #include <stdio.h>
     int main(int argc, char *argv[])
     {
         printf("Hello, world!\n");
         return 0;
     }

Would something like this help here?

Regards,
Philip Ashmore


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4F63D2A1.1040408@...

1234 ... 12