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?
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.
The image seems to basically define the package list for the image as
well as the format of the rootfs and boot media.
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.
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.
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.
I'd appreciate some discussion to help me clarify where these lines
should be.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
