[meta-intel] [PATCHv5 00/10] Runtime Machine Configuration (RMC)

Tom Zanussi tom.zanussi at linux.intel.com
Thu Aug 4 18:56:31 PDT 2016 

On 08/04/2016 08:42 PM, Jianxun Zhang wrote:
> 
>> On Aug 4, 2016, at 3:55 PM, Tom Zanussi <tom.zanussi at linux.intel.com> wrote:
>>
>> On 08/04/2016 05:41 PM, Jianxun Zhang wrote:
>>>
>>>> On Aug 4, 2016, at 2:26 PM, Tom Zanussi <tom.zanussi at linux.intel.com> wrote:
>>>>
>>>> On 08/04/2016 04:11 PM, Jianxun Zhang wrote:
>>>>>
>>>>>> On Aug 4, 2016, at 7:31 AM, Tom Zanussi <tom.zanussi at linux.intel.com> wrote:
>>>>>>
>>>>>> On 08/03/2016 07:49 PM, Jianxun Zhang wrote:
>>>>>>>
>>>>>>>> On Aug 3, 2016, at 4:15 PM, Tom Zanussi <tom.zanussi at linux.intel.com> wrote:
>>>>>>>>
>>>>>>>> Hi Jianxun,
>>>>>>>>
>>>>>>>> On 08/03/2016 01:04 PM, Jianxun Zhang wrote:
>>>>>>>>> Hi Saul, Tom & others,
>>>>>>>>>
>>>>>>>>> This is the V5 submission of RMC work with new enhancements and fixes over
>>>>>>>>> V4 also with some minor adjustments in rmc README file and commit messages.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Although I'm a bit dismayed that we seem to have come full circle and
>>>>>>>> are back at the EFI_PROVIDER="rmc-systemd-boot" interface, I went ahead
>>>>>>>> and merged these 10 patches anyway- it doesn't seem we'll be able to
>>>>>>>> make progress toward fleshing out this feature otherwise.
>>>>>>>
>>>>>>> I agree and also feel we are circling on this matter with what we can have now.
>>>>>>>
>>>>>>> () multiple switches are logically predictable if no overriding is allowed. We also need to clarify our thoughts on if we really want to have a single feature switch in this case.
>>>>>>>
>>>>>>> () What we can do is to seek/improve another interface in OE, not to use EFI_PROVIDER for non-bootloader RMC functions like db deployment stuff.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Please file a bug addressing that interface issue, as well as for the
>>>>>>>> other issues we identified along the way and that remain unaddressed.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, I will add this one into bz ticket list I am going to file, just waiting their merge (I just don’t feel filing bugs for pending patches make much sense technically.)
>>>>>>>
>>>>>>
>>>>>> All merged, so no need to wait now.  Please add me to the cc: list for
>>>>>> all the bugs you file related to this, thanks.
>>>>>
>>>>> Tom,
>>>>> This is the list of tickets I filed today. The first section is what I collected during submission. The later part is for other improvement in RMC and test case.
>>>>> I should have added you in CC list of each of them. But if I missed any, feel free to add yourself. Please also add comments for anything inaccurately reflects our discussion.
>>>>>
>>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10081
>>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10083
>>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10084
>>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10085
>>>>>
>>>>
>>>> Looks ok, but I think there are a couple things missing, mainly the
>>>> interface issue we keep going around in circles on, and there's
>>>> something about detecting errors at build-time, but nothing about runtime.
>>>>
>>> I think interface issue is captured in 10084. It decouples RMC with EFI_PROVIDER. But please feel free to file another bug if I get lost in circling.
>>>
>>> The installer show deployment information in console. I don’t think bootloader should fail or toss warning message when there is no data or db for a board.  Or are you suggesting anything else? Please feel free to assign me a ticket as a following up.
>>>
>>
>> You modify the bootloader to call libraries to gather data from the
>> board and query the rmc db.  The libraries and the database itself can
>> be buggy or corrupt, and cause unintended failures.  How does the user
>> differentiate a failure from these causes vs an expected lack of
>> configuration?
> 
> We start troubleshoot SW problems when we start to believe we did right but cannot get expected result. RMC is just another piece of software, so no difference here. If user believes everything is correct but SW doesn’t work as expected/documented, it is time to debug.
> 
> You just remind me that Cal once asked me  to add some dumpers to convert binaries (fingerprint and db) back to human-readable blobs for troubleshooting. I created another ticket for this request.
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10092
> 

Yes, that would definitely help a lot.

> But I don’t think these efforts will be capable of differentiating all unexpected results from wrong input and SW bug.
> 

It would probably be enough to have a settable mode that would be
verbose about what it was doing.

Combined with the dumper, I think that would be enough so that most of
the time you could figure out what's going on without resorting to a
debugger or adding printfs to the code..

Tom

>> Tom
>>
>>>> There are also minor things that were touched on, such as the complete
>>>> copy of the installer from oe-core, and forcing the user to specify each
>>>> part of the path individually to create a file in the installer, etc.
>>>>
>>> 10085 implicitly covers installer's copy topic. There will be no copy or patch of installer in meta-intel once RMC is in OE.
>>>
>>> I have explained why developers have to specify path for each file and shall not delegate this work to RMC (Thread "Re: [meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature”)
>>>
>>> I think you didn’t bother this before just because you don’t care it and assume “default” attribute of what copied to a target’s partition are always “right”. With the existing OE installer, how does user specify
>>> a FS attribute not default during installation, specifically when rootfs is read-only? This should be a generic topic, not RMC-specific.
>>>
>>>
>>>
>>>> Tom
>>>>
>>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10086
>>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10087
>>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10088
>>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10089
>>>>>
>>>>> I appreciate your effort on RMC review and merge, and specially enjoy our good discussion in these threads.
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> The most important ones in addition being:
>>>>>>>>
>>>>>>>> - rmc should be useful for all yocto-supported platforms, not just the
>>>>>>>> ones in meta-intel.  Because it only supports Intel platforms at the
>>>>>>>> moment, and to give it some exposure, it makes sense to have it in
>>>>>>>> meta-intel at least initially, but it really should be in oe-core.
>>>>>>>> Adding support for other platforms should also help generalize the code
>>>>>>>> in the process.  So please file a bug to add support for the other
>>>>>>>> platforms and move it out of meta-intel.
>>>>>>>>
>>>>>>>
>>>>>>> I agree with you to push it to OE, just want to be more precisely for supported scope even when it is in OE. RMC is based on EFI and SMBIOS so I should say any platforms with these FW features should be supported naturally.
>>>>>>> We have EFI features in OE already, so this won’t be a blocker. But for other arch not with required FW, I am not sure how much RMC could help.
>>>>>>>
>>>>>>
>>>>>> Well, the first step as implemented here requires those things.  But
>>>>>> surely the general idea of tailoring images based on fingerprints
>>>>>> generalizes to other platforms.
>>>>>>
>>>>>>> Also sharing my understanding on generating code/file approach in OE, I think when people don’t have an alternative solution to manage customizations, they need the approach. But I hope we can rethink it when a runtime solution
>>>>>>> is on horizon.
>>>>>>>
>>>>>>> I cannot see why providing variables, with logic behind them, to users could be better or more flexible than having board-specific files, if the later way can managed file copies outside of generic stack. 
>>>>>>>
>>>>>>> I don’t mind you or anyone forward this newbie’s opinion to any OE people, seriously. I do have concern on this OE philosophy.
>>>>>>>
>>>>>>> But I will file a ticket so that we can check in these thoughts and requirements.
>>>>>>>
>>>>>>>
>>>>>>>> - there currently is really no way to debug a failing rmc configuration
>>>>>>>> or run-time other than by inspection.  There needs to be support in both
>>>>>>>> the host and the target to flag invalid configurations and trace what's
>>>>>>>> happening at run-time when something goes wrong and it's not apparent
>>>>>>>> what the problem is.
>>>>>>>>
>>>>>>>
>>>>>>> RMC is designed as “don’t fail anything at runtime if we don’t fetch board-data successfully”. And image with RMC shall be functional on non-supported boards in general.
>>>>>>>
>>>>>>
>>>>>> Sorry, failing silently even if that maps to something legal isn't useful.
>>>>>>
>>>>>>> These design goals could be a part of reasons attracting complains.
>>>>>>>
>>>>>>> I will file a ticket for this with others. Let me see what I can improve, no worries.
>>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>>> I tried my best to keep doc, commit msg and function consistent when we
>>>>>>>>> modify the feature's behavior back and forth. Feel free to let me know any-
>>>>>>>>> thing out of sync...
>>>>>>>>>
>>>>>>>>> Jianxun Zhang (10):
>>>>>>>>> rmc: Add Runtime Machine Configuration (RMC) project
>>>>>>>>> gnu-efi: Add GUID for SMBIOS 3 entry point structure
>>>>>>>>> systemd-boot: load board-specific entry and kernel cmdline
>>>>>>>>> EFI installer: deploy board-specific data and kernel cmdline
>>>>>>>>> rmc: add recipe and bbclass for RMC feature
>>>>>>>>> rmc: document and examples for RMC feature
>>>>>>>>> rmc: support broxton-m platform
>>>>>>>>> rmc: support post-installation hook POSTINSTALL.sh
>>>>>>>>> rmc: update document and NUC Gen 6 for post-installation hook
>>>>>>>>> rmc: don't install boot entries when RMC entries exist
>>>>>>>>>
>>>>>>>>> classes/rmc-db.bbclass                             |  92 ++++++
>>>>>>>>> classes/rmc-systemd-boot.bbclass                   |  12 +
>>>>>>>>> ...d-GUID-for-SMBIOS-3-entry-point-structure.patch |  32 ++
>>>>>>>>> common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend      |   2 +
>>>>>>>>> .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG         |   2 +
>>>>>>>>> .../rmc/boards/T100-32bit/T100-32bit.fp            | Bin 0 -> 116 bytes
>>>>>>>>> common/recipes-bsp/rmc/boards/T100-32bit/boot.conf |   4 +
>>>>>>>>> .../recipes-bsp/rmc/boards/T100-32bit/install.conf |   4 +
>>>>>>>>> common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM |   1 +
>>>>>>>>> common/recipes-bsp/rmc/boards/broxton-m/bm.fp      | Bin 0 -> 83 bytes
>>>>>>>>> .../rmc/boards/minnowmax/BOOTENTRY.CONFIG          |   1 +
>>>>>>>>> common/recipes-bsp/rmc/boards/minnowmax/boot.conf  |   4 +
>>>>>>>>> .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp  | Bin 0 -> 143 bytes
>>>>>>>>> .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG        |   1 +
>>>>>>>>> .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf   |   4 +
>>>>>>>>> .../rmc/boards/minnowmaxB3/minnowmaxB3.fp          | Bin 0 -> 148 bytes
>>>>>>>>> .../rmc/boards/nucgen6/BOOTENTRY.CONFIG            |   2 +
>>>>>>>>> .../rmc/boards/nucgen6/INSTALLER.CONFIG            |   6 +
>>>>>>>>> common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM   |   1 +
>>>>>>>>> .../recipes-bsp/rmc/boards/nucgen6/POSTINSTALL.sh  |   7 +
>>>>>>>>> common/recipes-bsp/rmc/boards/nucgen6/boot.conf    |   4 +
>>>>>>>>> common/recipes-bsp/rmc/boards/nucgen6/install.conf |   4 +
>>>>>>>>> common/recipes-bsp/rmc/boards/nucgen6/mylib.conf   |   7 +
>>>>>>>>> common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp      | Bin 0 -> 149 bytes
>>>>>>>>> common/recipes-bsp/rmc/rmc-db.bb                   |  48 +++
>>>>>>>>> common/recipes-bsp/rmc/rmc.bb                      |  46 +++
>>>>>>>>> .../recipes-bsp/systemd-boot/systemd-boot.bbappend |  20 ++
>>>>>>>>> ...d-boot-Link-RMC-libraries-into-bootloader.patch |  31 ++
>>>>>>>>> ...d-board-specific-boot-entries-from-RMC-da.patch | 263 +++++++++++++++
>>>>>>>>> ...pport-global-kernel-command-line-fragment.patch |  66 ++++
>>>>>>>>> .../initrdscripts/files/init-install-efi.sh        | 339 ++++++++++++++++++++
>>>>>>>>> .../initramfs-live-install-efi_%.bbappend          |   1 +
>>>>>>>>> conf/layer.conf                                    |  10 +
>>>>>>>>> documentation/rmc/README                           | 356 +++++++++++++++++++++
>>>>>>>>> 34 files changed, 1370 insertions(+)
>>>>>>>>> create mode 100644 classes/rmc-db.bbclass
>>>>>>>>> create mode 100644 classes/rmc-systemd-boot.bbclass
>>>>>>>>> create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
>>>>>>>>> create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/install.conf
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM
>>>>>>>>> create mode 100755 common/recipes-bsp/rmc/boards/broxton-m/bm.fp
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/boot.conf
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/POSTINSTALL.sh
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/boot.conf
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/install.conf
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/mylib.conf
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/rmc-db.bb
>>>>>>>>> create mode 100644 common/recipes-bsp/rmc/rmc.bb
>>>>>>>>> create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot.bbappend
>>>>>>>>> create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-libraries-into-bootloader.patch
>>>>>>>>> create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot/0002-sd-boot-Load-board-specific-boot-entries-from-RMC-da.patch
>>>>>>>>> create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot/0003-sd-boot-Support-global-kernel-command-line-fragment.patch
>>>>>>>>> create mode 100644 common/recipes-core/initrdscripts/files/init-install-efi.sh
>>>>>>>>> create mode 100644 common/recipes-core/initrdscripts/initramfs-live-install-efi_%.bbappend
>>>>>>>>> create mode 100644 documentation/rmc/README
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

More information about the meta-intel mailing list