* is INITRAMFS_TASK still useful, or can it be tossed?
@ 2014-08-26 19:14 Robert P. J. Day
2014-08-26 19:43 ` Bruce Ashfield
0 siblings, 1 reply; 3+ messages in thread
From: Robert P. J. Day @ 2014-08-26 19:14 UTC (permalink / raw)
To: OE Core mailing list
just noticed the following -- here's snippets from kernel.bbclass:
... snip ...
INITRAMFS_TASK ?= ""
... snip ...
# NOTE: setting INITRAMFS_TASK is for backward compatibility
# The preferred method is to set INITRAMFS_IMAGE, because
# this INITRAMFS_TASK has circular dependency problems
# if the initramfs requires kernel modules
image_task = d.getVar('INITRAMFS_TASK', True)
if image_task:
d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
... snip ...
if [ "$use_alternate_initrd" = "" ] && [ "${INITRAMFS_TASK}" != "" ] ; then
# The old style way of copying an prebuilt image and building it
# is turned on via INTIRAMFS_TASK != ""
... snip ...
i have about a dozen layers checked out and the only other place i
see that variable used is:
meta-oe/meta-initramfs/recipes-kernel/linux/linux-yocto-tiny-kexecboot_3.10.bb:
INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_rootfs"
so has INITRAMFS_TASK been obsoleted by INITRAMFS_IMAGE? or is it
still worth hanging onto?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: is INITRAMFS_TASK still useful, or can it be tossed?
2014-08-26 19:14 is INITRAMFS_TASK still useful, or can it be tossed? Robert P. J. Day
@ 2014-08-26 19:43 ` Bruce Ashfield
2014-08-26 19:56 ` Robert P. J. Day
0 siblings, 1 reply; 3+ messages in thread
From: Bruce Ashfield @ 2014-08-26 19:43 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
On Tue, Aug 26, 2014 at 3:14 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
> just noticed the following -- here's snippets from kernel.bbclass:
>
> ... snip ...
> INITRAMFS_TASK ?= ""
> ... snip ...
> # NOTE: setting INITRAMFS_TASK is for backward compatibility
> # The preferred method is to set INITRAMFS_IMAGE, because
> # this INITRAMFS_TASK has circular dependency problems
> # if the initramfs requires kernel modules
> image_task = d.getVar('INITRAMFS_TASK', True)
> if image_task:
> d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
> ... snip ...
> if [ "$use_alternate_initrd" = "" ] && [ "${INITRAMFS_TASK}" != "" ] ; then
> # The old style way of copying an prebuilt image and building it
> # is turned on via INTIRAMFS_TASK != ""
> ... snip ...
>
> i have about a dozen layers checked out and the only other place i
> see that variable used is:
>
> meta-oe/meta-initramfs/recipes-kernel/linux/linux-yocto-tiny-kexecboot_3.10.bb:
> INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_rootfs"
check meta-handheld, it was an existing use case we didn't want to break.
Bruce
>
> so has INITRAMFS_TASK been obsoleted by INITRAMFS_IMAGE? or is it
> still worth hanging onto?
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
> ========================================================================
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: is INITRAMFS_TASK still useful, or can it be tossed?
2014-08-26 19:43 ` Bruce Ashfield
@ 2014-08-26 19:56 ` Robert P. J. Day
0 siblings, 0 replies; 3+ messages in thread
From: Robert P. J. Day @ 2014-08-26 19:56 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: OE Core mailing list
On Tue, 26 Aug 2014, Bruce Ashfield wrote:
> On Tue, Aug 26, 2014 at 3:14 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >
> > just noticed the following -- here's snippets from kernel.bbclass:
> >
> > ... snip ...
> > INITRAMFS_TASK ?= ""
> > ... snip ...
> > # NOTE: setting INITRAMFS_TASK is for backward compatibility
> > # The preferred method is to set INITRAMFS_IMAGE, because
> > # this INITRAMFS_TASK has circular dependency problems
> > # if the initramfs requires kernel modules
> > image_task = d.getVar('INITRAMFS_TASK', True)
> > if image_task:
> > d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
> > ... snip ...
> > if [ "$use_alternate_initrd" = "" ] && [ "${INITRAMFS_TASK}" != "" ] ; then
> > # The old style way of copying an prebuilt image and building it
> > # is turned on via INTIRAMFS_TASK != ""
> > ... snip ...
> >
> > i have about a dozen layers checked out and the only other place i
> > see that variable used is:
> >
> > meta-oe/meta-initramfs/recipes-kernel/linux/linux-yocto-tiny-kexecboot_3.10.bb:
> > INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_rootfs"
>
> check meta-handheld, it was an existing use case we didn't want to break.
ah, that wasn't one of the layers i had checked out, thanks.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-08-26 19:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-26 19:14 is INITRAMFS_TASK still useful, or can it be tossed? Robert P. J. Day
2014-08-26 19:43 ` Bruce Ashfield
2014-08-26 19:56 ` Robert P. J. Day
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox