[meta-intel] [PATCH 5/6] rmc: add recipe and bbclass for feature "rmc distro"
Jianxun Zhang
jianxun.zhang at linux.intel.com
Tue Jul 12 19:05:03 PDT 2016
> On Jul 12, 2016, at 5:21 PM, Saul Wold <saul.wold at intel.com> wrote:
>
> On Tue, 2016-07-12 at 16:53 -0700, Jianxun Zhang wrote:
>>>
>>> On Jul 12, 2016, at 4:29 PM, Saul Wold <saul.wold at intel.com> wrote:
>>>
>>> On Tue, 2016-07-12 at 10:59 -0700, Jianxun Zhang wrote:
>>>>
>>>> The new added recipe and bbclass put modified systemd-boot,
>>>> EFI installer and rmc work together to enable a single
>>>> generic image, built for multiple platforms, automatically
>>>> applies customization specific to the type of a running board.
>>>>
>>>> In another word, you will see a single image behaves differently
>>>> and intelligently according to the type of board it is running
>>>> on.
>>>>
>>>> To Enable this feature: add this line in conf file:
>>>> EFI_PROVIDER = "rmc-distro"
>>>>
>>> As mentioned before I strong discourage the use of distro here.
>>> Saul,
>> I don’t know much about naming rules in YP, but I am open for any
>> suggestions. I will fix it in V2 with any name reviewer are okay
>> with.
>>
> I think just rmc would be fine here, you can combine the 2 bbclasses
Saul,
The discussion around the last item in this mail explains why we should split rmc project and a RMC-based single image feature.
If you agree with the last item, the “rmc” terminology could be best for bare rmc project. I have a proposal at the last item, let me know if it’s okay.
>>
>>>
>>>>
>>>> For a supported board, this feature can :
>>>> () show and boot with board-specific boot entries in boot menu
>>>> in live-boot and post-installation.
>>>>
>>>> () apply a kernel cmdline fragment to the end of cmdline to boot
>>>> Linux kernel. This is effective for any boot entry user chooses
>>>> in
>>>> boto menu.
>>>>
>>>> () create directory and deploy files only for the type of the
>>>> running board to target's file systems. What left on target after
>>>> installation is just same as the result from installing a
>>>> conventional
>>>> image customized for a single type of hardware.
>>>>
>>>> To add support of new boards, a new variable
>>>> RMC_DISTRO_BOARD_DIRS
>>>> is the interface to developers. How-to information will be
>>>> provided
>>>> with examples in following patches.
>>>>
>>>> Signed-off-by: Jianxun Zhang <jianxun.zhang at linux.intel.com>
>>>> ---
>>>> classes/rmc-distro.bbclass | 49
>>>> ++++++++++++++++++++++++++++++++++++
>>>> common/recipes-bsp/rmc/rmc-distro.bb | 28 +++++++++++++++++++++
>>>> 2 files changed, 77 insertions(+)
>>>> create mode 100644 classes/rmc-distro.bbclass
>>>> create mode 100644 common/recipes-bsp/rmc/rmc-distro.bb
>>>>
>>>> diff --git a/classes/rmc-distro.bbclass b/classes/rmc-
>>>> distro.bbclass
>>>> new file mode 100644
>>>> index 0000000..a7fd226
>>>> --- /dev/null
>>>> +++ b/classes/rmc-distro.bbclass
>>>> @@ -0,0 +1,49 @@
>>>> +# RMC Distro class
>>>> +# EFI population is provided by EFI bootloader bbclasses and
>>>> called
>>>> by
>>>> +# image-live.bbclass. We haven't found another way to install a
>>>> file
>>>> +# from a non-bootloader project into EFI partition without an
>>>> extra
>>>> +# change in OE to do so. These functions are not exposed and
>>>> EFI_PROVIDER
>>>> +# seems the only chance we can ask image-live.bbclass to call a
>>>> procedure
>>>> +# we defined.
>>>> +#
>>>> +# Ideally, we should have a way to call the
>>>> ${EFI_CLASS}:efi_populate, and
>>>> +# append or prepend installing rmc database file logic to the
>>>> base.
>>>> +#
>>>> +# This class works as a workaround when we don't want to cause a
>>>> change in
>>>> +# OE. We simply copy efi_populate() from systemd-boot and append
>>>> rmc
>>>> +# distro installation in this function.
>>>> +#
>>>> +# The class is also intended to be the switch of rmc distro. Set
>>>> +# EFI_PROVIDER = "rmc-distro" in a conf file to enable it.
>>>> +
>>>> +IMAGE_INSTALL_append = " rmc"
>>>> +
>>>> +inherit systemd-boot
>>>> +
>>>> +do_bootimg[depends] += "${MLPREFIX}rmc-distro:do_deploy"
>>>> +
>>>> +efi_populate() {
>>>> + # original systemd-boot section
>>>> + DEST=$1
>>>> +
>>>> + EFI_IMAGE="systemd-bootia32.efi"
>>>> + DEST_EFI_IMAGE="bootia32.efi"
>>>> + if [ "${TARGET_ARCH}" = "x86_64" ]; then
>>>> + EFI_IMAGE="systemd-bootx64.efi"
>>>> + DEST_EFI_IMAGE="bootx64.efi"
>>>> + fi
>>>> +
>>>> + install -d ${DEST}${EFIDIR}
>>>> + # systemd-boot requires these paths for configuration
>>>> files
>>>> + # they are not customizable so no point in new vars
>>>> + install -d ${DEST}/loader
>>>> + install -d ${DEST}/loader/entries
>>>> + install -m 0644 ${DEPLOY_DIR_IMAGE}/${EFI_IMAGE}
>>>> ${DEST}${EFIDIR}/${DEST_EFI_IMAGE}
>>>> + install -m 0644 ${SYSTEMD_BOOT_CFG}
>>>> ${DEST}/loader/loader.conf
>>>> + for i in ${SYSTEMD_BOOT_ENTRIES}; do
>>>> + install -m 0644 ${i} ${DEST}/loader/entries
>>>> + done
>>>> +
>>> If this is all the same as the original systemd-boot efi_populate,
>>> you
>>> can just add the below via a efi_populate_append() function
>>>
>> I think the bbclass must explicitly export the function to do that,
>> but that requires a change in OE that
>> I want to avoid this time.
>>
>> I checked "3.4.5. Flexible Inheritance for Class Functions” in BB
>> user manual and that’s why patch is done this way.
>>
> Hmm, I just tested adding _append and it worked as I expected (got two
> copies of efi_populate in the script.
Saul,
Thanks to try it out. Did I misunderstand 3.4.5 in BB doc? hmm, I will change it in V2 if it works.
>
>>
>>>
>>> Why can't this be part of the rmc.bbclass?
>>>
>>>>
>>>> + # append logic to add rmc database file into EFI
>>>> partition.
>>>> + install -m 0400 ${DEPLOY_DIR_IMAGE}/rmc.db
>>>> ${DEST}/rmc.db
>>>> +}
>>>> diff --git a/common/recipes-bsp/rmc/rmc-distro.bb
>>>> b/common/recipes-
>>>> bsp/rmc/rmc-distro.bb
>>>> new file mode 100644
>>>> index 0000000..2fbe5bb
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/rmc-distro.bb
>>>> @@ -0,0 +1,28 @@
>>>> +SUMMARY = "RMC distro image"
>>>> +DESCRIPTION = "Generate a centralized RMC database for RMC
>>>> distro
>>>> image. \
>>>> +The fingerprints and data for all boards supported in distro
>>>> image
>>>> are \
>>>> +specified by variable RMC_DISTRO_BOARD_DIRS which is a list of
>>>> top \
>>>> +directories that contains subdirectories for boards. Developers
>>>> can
>>>> add \
>>>> +their top directories by appending them to this variable in a
>>>> bbappend \
>>>> +file of this recipe. Refer to rmc-native bbclass for details."
>>>> +
>>>> +LICENSE = "MIT"
>>>> +
>>>> +inherit rmc-native
>>>> +
>>>> +RMC_DISTRO_BOARD_DIRS ?= ""
>>> How about just RMC_BOARD_DATA_DIRS?
>> Sure. I know you don’t like “distro” here. No worries, all of this
>> will be fixed in V2.
>>>
>>>
>>>>
>>>> +RMC_DB_DIR = "${WORKDIR}/db"
>>>> +
>>>> +do_generate_rmc_db () {
>>>> + rmc_generate_db "${RMC_DISTRO_BOARD_DIRS}"
>>>> "${RMC_DB_DIR}"/rmc.db
>>>> +}
>>>> +
>>>> +addtask generate_rmc_db after do_compile
>>>> +
>>>> +inherit deploy
>>>> +
>>>> +do_deploy () {
>>>> + install -m 0400 ${RMC_DB_DIR}/rmc.db ${DEPLOYDIR} ||
>>>> true
>>>> +}
>>>> +
>>>> +addtask deploy after do_generate_rmc_db
>>> Why create a new recipe, can't this be part of the main rmc recipe?
>> The main recipe, assuming you mean rmc.bb, is for bare rmc project.
>> "rmc-distro” (sorry) is built based on rmc project. In this way,
>> these functions can work independently for reuse.
>>
>> () you can build rmc tool and libraries just like other projects
>> pulled in YP for target for target (and also host)
>> () You can use rmc-native class to build your RMC database in your
>> project’s local dir and decide how it is deployed into image.
>> This is done with rmc-native. What in rmc-distro.bb is just the first
>> _instance_ to use this service.
>>
> maybe rmc-db.bb then since it's provide the db file?
Saul,
I think it is a good idea because what it does is generate a centralized ‘db’ inside rmc project build path.
I propose these to address all feedbacks on naming in V2:
() rmc.bb -> rmc.bb (no change, it is for bare rmc project)
() rmc-distro.bb -> rmc-db.bb (as you suggested)
() rmc-native.bb -> (merged into rmc.bb, I will try it)
() rmc-native.bbclass -> rmc-db.bbclass (it uses native tool to make db)
() rmc-distro.bbclass-> rmc-boot.bbclass.
user sets EFI_PROVIDER=rmc-boot to enable rmc image feature. This is the only odd ball in my proposal, but it may not be totally absurd. It inherits systemd-boot anyway. Later we could use MACHINE_FEATURE or DISTRO_FEATURE to enable “rmc-image” feature to replace an EFI bootloader-like name to enable the whole thing. Assume the word “image” is okay here. :-)
>
>> Actually, as I said in cover, splitting bare rmc project and “rmc-
>> distro” is a big change since the old work people pulled.
>>
> I did not realize it was going to be this.
>> Thanks
>>
>>
>>>
>>>
>>> Sau!
>>>>
More information about the meta-intel
mailing list