> On Aug 4, 2016, at 2:26 PM, Tom Zanussi <[email protected]> wrote:
> 
> On 08/04/2016 04:11 PM, Jianxun Zhang wrote:
>> 
>>> On Aug 4, 2016, at 7:31 AM, Tom Zanussi <[email protected]> wrote:
>>> 
>>> On 08/03/2016 07:49 PM, Jianxun Zhang wrote:
>>>> 
>>>>> On Aug 3, 2016, at 4:15 PM, Tom Zanussi <[email protected]> 
>>>>> 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.

> 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
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-- 
_______________________________________________
meta-intel mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-intel

Reply via email to