All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Zacarias <gustavo@zacarias.com.ar>
To: buildroot@busybox.net
Subject: [Buildroot] issues without busybox
Date: Mon, 21 Jul 2014 17:28:24 -0300	[thread overview]
Message-ID: <53CD77E8.7050208@zacarias.com.ar> (raw)
In-Reply-To: <20140721221555.72df12ca@free-electrons.com>

On 07/21/2014 05:15 PM, Thomas Petazzoni wrote:
> I believe one direction we should potentially investigate is to have
> one common skeleton for the base stuff, and then separate additional
> skeletons for busybox init, sysv init and systemd init.

Hi.
I think i've already mentioned i'm planning on a proposal to revamp the
init system/initscript options.
The idea would be to make them consistent and document how a proper
initscript should be made, and get them all in line with this.
Also interesting would be to make them configurable, in many cases
daemons have options and don't use a configuration file, so let's make
one i say. Actually let's make two :) A default file for read-only
filesystem, and some another that overrides the default, good for RO
filesystems which have a separate partition for that.
We could make the start/stop order configurable too via a file similar
to the device table, if this file lives in the target filesystem it
could be nicer too - but well that depends on how far we'd like to go.
The idea would be to use as much pure shell as possible for this to keep
necessary dependencies to a minimum.
Haven't thought out much of the systemd option yet, i need to dig
somewhat deeper into it, or it could be handled separately since it's
quite different from the usual inits.

> Regarding the specific issues you're raising here, I'm not exactly sure
> how to solve them:
> 
>  * For the network, we could make sysvinit depend on ifupdown, but this
>    sounds a bit strong. Then it would mean that we should make the init
>    script installation conditional. Or maybe installed just by ifupdown
>    on one side, and busybox on the other side?

We can make the different BR2_INIT_* options select what's appropiate,
if someone wants to "roll their own" they can select None.

>  * Regarding start-stop-daemon, I believe all (most?) our init scripts
>    rely on start-stop-daemon. So I'm not sure how to handle that...

We can throw a compatibility function/alias/script for different scenarios.
But i think getting what we want to do on a clean sheet would be best,
and then work on the patches.
Regards.

  reply	other threads:[~2014-07-21 20:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21 19:57 [Buildroot] issues without busybox Gilles
2014-07-21 20:15 ` Thomas Petazzoni
2014-07-21 20:28   ` Gustavo Zacarias [this message]
2014-07-21 21:35     ` Gilles
2014-07-22 10:31       ` Gustavo Zacarias
2014-07-22 12:17     ` Eric Le Bihan
2014-07-22 12:34       ` Gustavo Zacarias
2014-07-25 11:00 ` Peter Korsgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53CD77E8.7050208@zacarias.com.ar \
    --to=gustavo@zacarias.com.ar \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.