[OE-core] [PATCH 1/2] busybox: Add support for busybox-init

[Khem Raj]

On Mon, Feb 1, 2016 at 12:14 AM, Patrick Ohly <patrick.ohly at intel.com> wrote:
> On Mon, 2016-01-25 at 11:39 -0800, Andre McCurdy wrote:
>> > +        if grep "CONFIG_INIT=y" ${B}/.config; then
>> > +                install -D -m 0777 ${WORKDIR}/rcS
>> ${D}${sysconfdir}/init.d/rcS
>> > +                install -D -m 0777 ${WORKDIR}/rcK
>> ${D}${sysconfdir}/init.d/rcK
>> > +                install -D -m 0755 ${WORKDIR}/runlevel
>> ${D}${base_sbindir}/runlevel
>> > +                if grep "CONFIG_FEATURE_USE_INITTAB=y"
>> ${B}/.config; then
>> > +                        install -D -m 0777 ${WORKDIR}/inittab
>> ${D}${sysconfdir}/inittab
>> > +                        tmp="${SERIAL_CONSOLES}"
>> > +                        for i in $tmp
>> > +                        do
>> > +                                j=`echo ${i} | sed s/\;/\ /g`
>> > +                                label=`echo ${i} | sed -e 's/tty//'
>> -e 's/^.*;//' -e 's/;.*//'`
>> > +                                echo "tty$label::respawn:
>> ${base_sbindir}/getty ${j}" >> ${D}${sysconfdir}/inittab
>> > +                        done
>> > +                fi
>> > +        fi
>
> SERIAL_CONSOLES is typically set differently for different machines. But
> busybox is not machine-specific, therefore using SERIAL_CONSOLE like
> this prevents sstate/package reuse or worse, causes package versioning
> problems.

when busybox is used as init system then it becomes machine specific and we have
a choice to do so which is disabled by default.

>
> This probably was not noticed by the auto-testers because it only causes
> tests to fail when SERIAL_CONSOLES is really set differently. I'm
> wondering whether there should be variable flag for machine-specific
> variables: then using such variables in machine-independent recipes
> could trigger a QA warning.
>


> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>