From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Darren Hart <dvhart@linux.intel.com>
Cc: Yocto Project <yocto@yoctoproject.org>
Subject: Re: The role of "distro" and "image"
Date: Tue, 13 Dec 2011 21:36:10 +0000 [thread overview]
Message-ID: <1323812170.25491.23.camel@ted> (raw)
In-Reply-To: <4EE7B44D.7000301@linux.intel.com>
On Tue, 2011-12-13 at 12:23 -0800, Darren Hart wrote:
> I'm trying to wrap up my work on meta-tiny and integrate it into poky
> proper. I'm having some difficulty drawing a line between the
> responsibility of the distro definition versus that of the image definition.
>
> For example, if I define a distro which uses tmpdevfs (no udev or mdev)
> and specifies KMACHINE=yocto/standard/tiny to build the tiny variant of
> the linux-yocto kernel, and customizes the busybox build to leave out
> various things - would it make sense for someone to then try to build
> core-image-sato with it? It doesn't to me, but nothing prevents the user
> from doing that (other than a likely build failure).
>
> So what does the distro define and what does the image define?
I think Joshua's response is in line with what I'm thinking. Distro is
where all the policy is specified. The image is just a list of pieces of
software to include, its not meant to be much more than that.
> Digging around in conf/distro for meta and meta-yocto, I see things like
> naming convention, additional dependencies, choice of toolchain and
> libc, source mirrors, default virtual providers, etc.
Right, all of this is "policy" at some level or another.
> The image seems to basically define the package list for the image as
> well as the format of the rootfs and boot media.
The latter is often machine specific. There are some images which
specify those things but they're a minority.
> If I understand this correctly, a new "tiny" distro definition would
> change the preferred linux-yocto provider to a linux-yocto-tiny recipe
> (which would in turn specify the default KMACHINE/KTYPE as well, the
> TCLIBC, DISTRO_FEATURES_LIBC, and some naming rules.
Yes, you'd inherit something for the base config and then customise it.
> I currently define a new task-core-tiny.bb to reset some
> MACHINE_ESSENTIAL bits (qemu pulls in more than is necessary for tiny)
> and redefine the REDEPENDS for the image. I believe I could do this
> instead with assignments in the new distro definition and reuse
> task-core-boot.bb.
The latter reuse of task-core-boot would be ideal. If that can't work
I'd be interested to see why and if we couldn't enhance it so it could
work.
> As for images, I might be able to reuse core-image-minimal - but it
> oddly contains "${POKY_EXTRA_INSTALL}" in the IMAGE_INSTALL. Since
> core-image-minimal.bb is defined in oe-core and POKY is a distro notion
> of meta-yocto, this contributes to my confusion over distro vs. image.
This is a bug and there are some patches out there to turn it into
COREIMAGE_EXTRA_INSTALL. Its a feature of the core-image.bbclass
(formerly poky.bbclass, hence the name confusion).
Not all images can be built with a given distro, our base config is
rather ride ranging though for obvious reasons. You could "enforce" this
by adding some anonymous python to the distro which does something like:
if inherits("image") and PN != core-image-minimal:
raise SkipPackage("Image PN not compatible with DISTRO=XXX")
Cheers,
Richard
next prev parent reply other threads:[~2011-12-13 21:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-13 20:23 The role of "distro" and "image" Darren Hart
2011-12-13 20:36 ` Joshua Lock
2011-12-13 20:39 ` Khem Raj
2011-12-13 21:36 ` Richard Purdie [this message]
2011-12-13 21:45 ` Chris Larson
2011-12-15 17:29 ` Koen Kooi
2011-12-15 17:54 ` Chris Larson
2011-12-15 21:18 ` Richard Purdie
2011-12-15 22:56 ` Chris Larson
2011-12-15 23:06 ` Richard Purdie
2011-12-15 23:09 ` Chris Larson
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=1323812170.25491.23.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=dvhart@linux.intel.com \
--cc=yocto@yoctoproject.org \
/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.