8191 2015-08-21 07:03:21 +0000 apply kernel config fragments to arbitrary kernels 2026-05-28 14:29:19 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel unspecified All Multiple IN PROGRESS REVIEW Medium+ enhancement 6.1 M3 1 patrick.ohly bruce.ashfield akuster brian.avery bruce.ashfield eduardas JPEWhacker kergoth randy.macleod sgw tom.zanussi --- --- Yes (doc changes required) oldest_to_newest 53307 0 patrick.ohly 2015-08-21 07:03:21 +0000 Suppose you have a functional layer which needs to apply certain kernel fragments to the kernel (example: enable Smack, see https://github.com/01org/meta-intel-iot-security/tree/master/meta-security-smack/recipes-kernel/linux-yocto). The layer is meant to be agnostic of the actual BSP it is used with, so it cannot make (strict) assumptions about the name of the kernel recipe. That rules out using, for example, a linux-yocto_%.bbappend, because there are BSPs where the kernel is not called "linux-yocto", even if it includes linux-yocto.inc. Copies of the .bbappend or symlinks for all known kernels do not work either, because then the layer cannot be used unless all of these kernel recipes are present (which is not the case when using BSP layers only when needed). It also does not scale. What happens to work at the moment is a linux-%.bbappend, which merely assumes that the kernel recipe starts with "linux-". That's because wildcard matching in cooker.py:get_file_appends() is fairly simplistic. However, this aspect of the implementation is not guaranteed because % is only documented as matching the version part. As an aside, it's worth pointing out though that a "foo_%.bbappend" does not match a foo.bb, which it probably should match?! Extra care must be taken in such a linux-%.bbappend to not make changes to recipes which are not actually kernel recipes, like this: FILESEXTRAPATHS_prepend := "${THISDIR}/linux-yocto:" SRC_URI_append = " ${@bb.data.inherits_class('kernel', d) and ' \ file://some-kernel-config.cfg \ ' \ or ''}" For this to work officially, the meaning of % in a .bbappend would have to be changed. That's a change in bitbake's documentation (but not the code, unless you also want to deal with the foo_%.bbappend -> foo.bb issue). The alternative discussed with rewitt on IRC was to not use a .bbappend at all, and instead let the layer.conf list additional kernel config fragments in a variable. The downside of that is that it is less obvious that the kernel gets modified by a layer, and mechanisms like BBMASK cannot be used. That would be a change in the kernel.bbclass. 53372 1 patrick.ohly 2015-08-25 06:55:23 +0000 meta-intel-iot-security now uses linux-%.bbappend. See https://github.com/01org/meta-intel-iot-security/pull/38 and https://github.com/pohly/meta-intel-iot-security/commit/2515e235c02a452f4fe4c558f2e2d3839b1ac4fd for the actual commit. Better solutions welcome :-/ 54683 2 kergoth 2015-09-25 16:13:11 +0000 It's worth noting that if you truly want this to be *truly* agnostic of the actual BSP it's used with, then we need all kernel recipes to support config fragments, but that's not the case today. Today it's linux-yocto and whatever BSP kernels inject their own merge_configs.sh usage :) 54684 3 bruce.ashfield 2015-09-25 16:21:33 +0000 The update to the bug, prompted me to realize that I had left the state as "new". I've fixed that now. Indeed, the broader fragment support had the stage set in the upcoming 2.0 release, and in 2.1, the next steps can come in (just not enough hours in the day! :) 58750 4 bruce.ashfield 2016-02-08 22:01:37 +0000 This change is big enough, that M3 is not the time to introduce it. Moving it to 2.2, so the implementation can get more mileage. 61217 5 bruce.ashfield 2016-04-14 14:44:25 +0000 Design & implementation complete for arbitrary fragment support .. or more precisely "on demand" fragment support. Will send out the changes for the 1.2 cycle .. after they've had a good long soak. 61233 6 kergoth 2016-04-14 15:33:11 +0000 Is the design available for review anywhere, or the implementation on a branch for folks to poke at yet, or holding off till 2.2? 61234 7 bruce.ashfield 2016-04-14 15:40:30 +0000 (In reply to comment #6) > Is the design available for review anywhere, or the implementation on a > branch for folks to poke at yet, or holding off till 2.2? It's dirty at the moment .. functional, but needs more tweaking. I want to re-base it off some new 2.2 work (the fragment auditing and "why it was dropped" support), so I'm still sitting on it locally to avoid distraction. I will put it out in M1 for RFC, and make sure to copy you. 66506 8 bruce.ashfield 2016-09-22 16:17:33 +0000 As much as we can get into 2.2 is done and in the tree. This can be completed in the 2.3 cycle. 70526 9 bruce.ashfield 2017-02-08 04:34:35 +0000 re-working the implementation. This is unlikely for M3, and is too big for m4. So I'm preemptively moving this out, but will continue to work on it. 75209 10 brian.avery 2017-07-20 22:09:50 +0000 +brian&saul 75211 11 bruce.ashfield 2017-07-20 22:26:40 +0000 moving to m3. meeting the varied requirements and allowing the kernel-cache to be used without .scc files has caused some re-work. Rather than rush it, I'll do this for M3. 75912 12 bruce.ashfield 2017-08-16 17:33:16 +0000 Bumping this, now that the new design is in implementation. The strategy is streamlined/simple non invasive fragment merging in the core kernel bbclass. Even that support is only triggered when a .cfg is detected in the SRC_URI. kernel-yocto maintains the .scc (aka inclusion/integrated features + frags) and configuration audit functionality. shared kernel configuration fragments (which is important for re-use) can come in via kernel-meta repositories in the SRC_URI (optionally with the fetcher only bringing in specified fragments) + a variable that instructs the configuration merging to process fragments from that external meta store. We want to promote/leave the door open for fragment re-use, since otherwise we end up with a soup of namespace colliding fragments (assuming anyone actually uses it). 76003 13 bruce.ashfield 2017-08-18 22:12:35 +0000 Reducing the days to 2. Implementation is done, and I can build all the linux-yocto variants against it without regression. custom kernels can also do defconfig + fragments with support enabled via the presence of frags in the src_uri. The 2 remaining days is for review and extended regression testing. 76733 14 bruce.ashfield 2017-09-11 18:34:57 +0000 Change is available here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/fragments And I've also attached the patch 76734 15 4001 bruce.ashfield 2017-09-11 18:35:36 +0000 Created attachment 4001 arbitrary kernel fragments 78031 16 patrick.ohly 2017-11-07 16:07:10 +0000 (In reply to comment #14) > Change is available here: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/fragments > > And I've also attached the patch I'm not sure how this solves the problem. You are adding support for kernel config fragments to non-linux-yocto kernels, but then the original problem remains: how can a layer or distro change the configuration of the kernel without knowing the actual kernel recipe name? A more recent example is how tpm.scc and tpm2.scc are defined by meta-measured and meta-security (both basically have the same code): https://github.com/flihp/meta-measured/tree/master/recipes-kernel/linux There's a bunch of .bbappends. But that only works for certain well-known and common kernels. Appending to KERNEL_FEATURES globally kind of works if the referenced feature is defined in meta data cache of the kernel. But I can't see how one can add a custom .scc/.cfg in a clean way. 78032 17 bruce.ashfield 2017-11-07 16:54:16 +0000 (In reply to comment #16) > (In reply to comment #14) > > Change is available here: > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/fragments > > > > And I've also attached the patch > > I'm not sure how this solves the problem. You are adding support for kernel > config fragments to non-linux-yocto kernels, but then the original problem > remains: how can a layer or distro change the configuration of the kernel > without knowing the actual kernel recipe name? That was *never* my original problem. The problem was to bring fragment support to kernel's that want to use them. You should never apply a fragment to a kernel without knowing the target. Since the capabilities vary based on version and patching. > > A more recent example is how tpm.scc and tpm2.scc are defined by > meta-measured and meta-security (both basically have the same code): > https://github.com/flihp/meta-measured/tree/master/recipes-kernel/linux > > There's a bunch of .bbappends. But that only works for certain well-known > and common kernels. > > Appending to KERNEL_FEATURES globally kind of works if the referenced > feature is defined in meta data cache of the kernel. But I can't see how one > can add a custom .scc/.cfg in a clean way. Setting KERNEL_FEATURES searches any layer/directory structure that has a kernel-meta repo or a fragment. So that is the suggested mechanism. Add your fragments grouping via a kmeta SRC_URI and then select them via KERNEL_FEATURES. 78036 18 patrick.ohly 2017-11-07 18:26:27 +0000 (In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #14) > > > Change is available here: > > > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/fragments > > > > > > And I've also attached the patch > > > > I'm not sure how this solves the problem. You are adding support for kernel > > config fragments to non-linux-yocto kernels, but then the original problem > > remains: how can a layer or distro change the configuration of the kernel > > without knowing the actual kernel recipe name? > > That was *never* my original problem. But it is what this issue here is about. > You should never apply a fragment to a kernel without knowing > the target. Since the capabilities vary based on version and > patching. Some features like Smack and or TPM support are generic enough that it would make sense to enable them for arbitrary kernel recipes, provided that the kernel recipe supports config fragments. > > Appending to KERNEL_FEATURES globally kind of works if the referenced > > feature is defined in meta data cache of the kernel. But I can't see how one > > can add a custom .scc/.cfg in a clean way. > > Setting KERNEL_FEATURES searches any layer/directory structure that > has a kernel-meta repo or a fragment. So that is the suggested > mechanism. Add your fragments grouping via a kmeta SRC_URI and then > select them via KERNEL_FEATURES. So there can be more than one kmeta SRC_URI entry? I read the documentation today again and that part was not clear to me. But that still doesn't address the problem from the description: how can SRC_URI be set without knowing the name of the kernel recipe? But how can one set t 78037 19 bruce.ashfield 2017-11-07 19:09:22 +0000 (In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > (In reply to comment #14) > > > > Change is available here: > > > > > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/fragments > > > > > > > > And I've also attached the patch > > > > > > I'm not sure how this solves the problem. You are adding support for kernel > > > config fragments to non-linux-yocto kernels, but then the original problem > > > remains: how can a layer or distro change the configuration of the kernel > > > without knowing the actual kernel recipe name? > > > > That was *never* my original problem. > > But it is what this issue here is about. Fair enough. I've had a bug open for two years about moving the fragment support into a more general location. That is what I was using this for. .. I have no intention of changing the way that the meta data is separated from kernel providers and recipes. So I'll create a new bug for my work. > > > You should never apply a fragment to a kernel without knowing > > the target. Since the capabilities vary based on version and > > patching. > > Some features like Smack and or TPM support are generic enough that it would > make sense to enable them for arbitrary kernel recipes, provided that the > kernel recipe supports config fragments. TPM ? definitely not, that requires h/w to be truly useful. But even with a better example, not actually useful IMHO this is an area that you really shouldn't be throwing features out and hope that they stick in the kernel you are building. > > > > Appending to KERNEL_FEATURES globally kind of works if the referenced > > > feature is defined in meta data cache of the kernel. But I can't see how one > > > can add a custom .scc/.cfg in a clean way. > > > > Setting KERNEL_FEATURES searches any layer/directory structure that > > has a kernel-meta repo or a fragment. So that is the suggested > > mechanism. Add your fragments grouping via a kmeta SRC_URI and then > > select them via KERNEL_FEATURES. > > So there can be more than one kmeta SRC_URI entry? I read the documentation > today again and that part was not clear to me. Yep. You can have as many as you want. The docs may be out date or lagging. > > But that still doesn't address the problem from the description: how can > SRC_URI be set without knowing the name of the kernel recipe? > It can't. As I mentioned above, this is talking about breaking the separation of the meta data from the recipe that is processing those variables. That's not a separation that I'm willing to break, but it is what KERNEL_FEATURES can do if it was part of the global configuration namespace .. which isn't entirely a great idea. To provide a feature like you are talking about, a layer can have a kernel meta available, and a kernel recipe that someone is building can use it. Simply including a layer should not modify the kernel configuration unless it is asked for (like the yocto compatibility changes that have been happening throughout the various layers). So unless a kernel recipe asks for a feature (via KERNEL_FEATURES) or a specific kernel is targeted .. this is not a good thing to have in a layer. > > But how can one set t 78041 20 patrick.ohly 2017-11-07 21:15:28 +0000 (In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > Some features like Smack and or TPM support are generic enough that it would > > make sense to enable them for arbitrary kernel recipes, provided that the > > kernel recipe supports config fragments. > > TPM ? definitely not, that requires h/w to be truly useful. Of course, but a kernel with TPM support will work fine on a device without TPM hardware. So it is not unreasonable to enable the feature, just in case, and then check at runtime in userspace whether the hardware is present. > > But that still doesn't address the problem from the description: how can > > SRC_URI be set without knowing the name of the kernel recipe? > > > > It can't. As I mentioned above, this is talking about breaking the > separation of the meta data from the recipe that is processing > those variables. > > That's not a separation that I'm willing to break, but it is what > KERNEL_FEATURES can do if it was part of the global configuration > namespace .. which isn't entirely a great idea. > > To provide a feature like you are talking about, a layer can have > a kernel meta available, and a kernel recipe that someone is building > can use it. That's exactly where things become complicated. There are various layers (Smack, TPM, Brian's work with containers) that try to be easy to use in the sense that a) adding the layer and b) setting some global config variable or sourcing a config file is enough to activate the functionality of the layer. That ease of use is gone once developers have to start reconfiguring their kernel recipe. A distro that supports arbitrary BSPs also can't help there. 78042 21 bruce.ashfield 2017-11-07 22:13:44 +0000 (In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > (In reply to comment #17) > > > Some features like Smack and or TPM support are generic enough that it would > > > make sense to enable them for arbitrary kernel recipes, provided that the > > > kernel recipe supports config fragments. > > > > TPM ? definitely not, that requires h/w to be truly useful. > > Of course, but a kernel with TPM support will work fine on a device without > TPM hardware. So it is not unreasonable to enable the feature, just in case, > and then check at runtime in userspace whether the hardware is present. > We'll disagree on this point .. I've been fighting this battle for 13 years. If a fragment applies and is enabled, people think it will work. No amount of holding our breath and hoping they'll look at the actual h/w to determine if it really will work will make it happen .. they simply don't. So there's a contract between the kernel -> BSP that if an option is enabled, it really has to have the supported h/w in that BSP. See my old bugs that talk about machine features, distro features and kernel features all working in coordination. This is not something we solve by arbitrarily applying configs to a kernel when a layer is included. > > > But that still doesn't address the problem from the description: how can > > > SRC_URI be set without knowing the name of the kernel recipe? > > > > > > > It can't. As I mentioned above, this is talking about breaking the > > separation of the meta data from the recipe that is processing > > those variables. > > > > That's not a separation that I'm willing to break, but it is what > > KERNEL_FEATURES can do if it was part of the global configuration > > namespace .. which isn't entirely a great idea. > > > > To provide a feature like you are talking about, a layer can have > > a kernel meta available, and a kernel recipe that someone is building > > can use it. > > That's exactly where things become complicated. There are various layers > (Smack, TPM, Brian's work with containers) that try to be easy to use in the > sense that a) adding the layer and b) setting some global config variable or > sourcing a config file is enough to activate the functionality of the layer. > > That ease of use is gone once developers have to start reconfiguring their > kernel recipe. A distro that supports arbitrary BSPs also can't help there. ... and that's not something we are going to solve for the kernel in any different way from the rest of the ecosystem. The bug that Brian raised about setting kernel options in local.conf was reject by myself, RP and others, for the reasons I'm giving here. You just don't break the separation of recipes -> global config in that way. You can always set kernel features in those very same files by using the _pn notation on a variable. There has already been a push for layers to exactly not do this. If you include a layer, it does nothing until you enable a DISTRO or other feature that triggers the functionality. No bbappends, etc, that change package configurations unless explicitly enabled. That's how we now do it in meta-virtualization. If someone is doing their work, and it requires kernel features, it really isn't too much to ask that they understand which kernel they are building and the name of the recipe so they can enable the functionality. But if it is too much to ask, then maybe something in anonymous python or a bitbake mod like you are talking about would be possible, but that functionality still will only be enabled when a distro or other flag is set. So while I recognize that the goal is noble, it just isn't something that is broadly going to happen .. unless there's a complete shift in yocto compliance and the ability to include a layer and have it do nothing. What I can do, and what I'm doing here, is make sure that if a layer has kernel configuration fragments that they can be selected via KERNEL_FEATURES (or via another type of include) and then applied to any kernel, even if it isn't based on kernel-yocto directly. 78054 22 patrick.ohly 2017-11-08 10:19:44 +0000 (In reply to comment #19) > (In reply to comment #18) > > > That was *never* my original problem. > > > > But it is what this issue here is about. > > Fair enough. I've had a bug open for two years about moving the > fragment support into a more general location. That is what I > was using this for. I'm moving this issue back to "NEW" so that it can be triaged again. (In reply to comment #21) > (In reply to comment #20) > > Of course, but a kernel with TPM support will work fine on a device without > > TPM hardware. So it is not unreasonable to enable the feature, just in case, > > and then check at runtime in userspace whether the hardware is present. > > > > We'll disagree on this point .. I've been fighting this battle > for 13 years. > > If a fragment applies and is enabled, people think it will work. > > No amount of holding our breath and hoping they'll look at the > actual h/w to determine if it really will work will make it happen > .. they simply don't. > > So there's a contract between the kernel -> BSP that if an option > is enabled, it really has to have the supported h/w in that BSP. Huh? Then why are there kernels with support for IDE, SATA and SCSI when actual boards only support a subset of that? This stance that "it really has to have the supported h/w in that BSP" sounds rather extreme to me and a poor fit for BSPs which try to support a variety of different devices. I agree that it makes sense for BSPs that target only one specific hardware configuration. > This is not something we solve by arbitrarily applying configs to > a kernel when a layer is included. I'm not advocating that merely including a layer should be enough. That would clearly go against "Yocto Compatible 2.0". > ... and that's not something we are going to solve for the kernel in any > different way from the rest of the ecosystem. The rest of the stack often looks at distro features. A "tpm" or "tmp2" distro feature make sense to me. Specifically in Refkit I'd like to use that to enable whole-disk encryption support based on a TPM. That works for individual recipes, just not for the kernel. It does not work because adding distro-specific changes (like enabling TPM based on a distro feature) to a BSP would limit the usage of the BSP to that distro. It does not work in the distro because the distro can't know which BSP is going to be used. This is the catch-22 that somehow needs to be solved. If the general consensus is that this problem should be punted to developer who sets up a build configuration, then okay, let's close this issue as "wontfix". Personally I think it would be better to address the problem in a more developer-friendly way. Checking KERNEL_FEATURES is one piece of the puzzle. What's missing is adding the necessary feature definitions without knowing the kernel recipe. How about supporting a KERNEL_META variable that supports listing additional meta repository URLs in the same way as SRC_URI? 78056 23 bruce.ashfield 2017-11-08 13:22:41 +0000 I clearing the date, and giving this one to RP. I will be submitting my kernel fragment support for any kernel, regardless, but this needs RPs architectural input. But as for layers applying features/fragments to arbitrary kernel recipes without needing a bbappend for the specific kernel recipe, that isn't something that I think is a good idea, or a separation of meta data that I want to break. If Richard agrees that the idea is sound, and that there's no other existing mechanism for this, then whatever support form it takes, I'll make sure it works for the kernel, but it won't be a kernel specific overall implementation since any package (i.e. u-boot, X, etc) could also use something like this. 78070 24 bruce.ashfield 2017-11-08 17:42:35 +0000 I can answer these questions as well as anyone else (no insult to Saul). The entire point of me assigning it to RP was to actually get *his* input. I'll take it back, and ask via email. 78071 25 bruce.ashfield 2017-11-08 17:43:12 +0000 ... and clearing the date again. I'm not sure why there's so much mucking happening with these cases. 79658 26 akuster 2018-03-01 18:33:55 +0000 is this change still applicable to master and can we get it submitted? if not, can we close as wontfix. I won the lottery an got the AR from the bug triage meeting : ) 79705 27 bruce.ashfield 2018-03-05 10:44:58 +0000 (In reply to comment #26) > is this change still applicable to master and can we get it submitted? if > not, can we close as wontfix. > > I won the lottery an got the AR from the bug triage meeting : ) Ha! The answer is somewhere in the middle of the options: - the patch is absolutely still valid for master, I build with this for everything I do - I've missed the cutoff for the release, but will immediately submit it for the next cycle - With CVEs, kernel-devsrc and this bug having some lively discussion about what is possible, the time to bike-shed this on the oe-core mailing list never came about. I'll update the target for this, do some tweaks and attach a new variant. 83880 28 bruce.ashfield 2019-05-22 20:51:11 +0000 My patches are still complete/valid for this, but it is hard to commit to it in the 2.8 timeframe. I'll take it through another set of test cycles and then see if it can be ready by the M3 timeframe .. but I'm still leaving it as 2.99. 85304 29 randy.macleod 2019-10-10 15:02:36 +0000 Bruce, Can we move this to a 3.1 milestone? If so pick one please. 85999 30 akuster 2020-01-09 16:00:59 +0000 (In reply to comment #29) > Bruce, Can we move this to a 3.1 milestone? If so pick one please. Does http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes?id=eac8f2f9ca26bf8cdb7f554803fd73c73b0b576e help this? 86724 31 4649 bruce.ashfield 2020-03-16 19:57:22 +0000 Created attachment 4649 Patch for fragments for all kernels v2. Refreshing the reference patch to apply to latest master. 88250 32 bruce.ashfield 2020-09-28 08:31:24 +0000 *** Bug 14064 has been marked as a duplicate of this bug. *** 88371 33 kergoth 2020-10-12 16:23:01 +0000 Note that do_merge_config cannot be used without kernel-yocto with the current patch unless you add the 'depends' that are currently only set on kernel_configme in kernel-yocto either to your custom kernel_configme or to merge_config, as merge_config requires them as well. 94090 34 bruce.ashfield 2022-09-29 15:03:39 +0000 This is still a valid concept, so bumping it to 4.2 for more consideration. 99934 35 randy.macleod 2024-10-17 19:04:15 +0000 Bulk move of medium importance bugs from 5.1 to 5.2 on behalf of Bruce. 4001 2017-09-11 18:35:36 +0000 2017-09-11 18:35:36 +0000 arbitrary kernel fragments 0001-kernel-make-kernel-configuration-fragments-available.patch text/plain 6884 bruce.ashfield RnJvbSA3M2I2NDA0ZTNkMTBkNTZjYWRlMzVkNDQ0NzEyYmY5ZDc5M2M4ZGMzIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCcnVjZSBBc2hmaWVsZCA8YnJ1Y2UuYXNoZmllbGRAd2luZHJp dmVyLmNvbT4KRGF0ZTogTW9uLCAxNCBBdWcgMjAxNyAxMTo1NjoxNyAtMDQwMApTdWJqZWN0OiBb UEFUQ0hdIGtlcm5lbDogbWFrZSBrZXJuZWwgY29uZmlndXJhdGlvbiBmcmFnbWVudHMgYXZhaWxh YmxlIHdpdGhvdXQKIGtlcm5lbC15b2N0bwoKQWx0aG91Z2gga2VybmVsLXlvY3RvIGhhcyBhbHdh eXMgc3VwcG9ydGVkIGtlcm5lbCBjb25maWd1cmF0aW9uCmZyYWdtZW50cyBpdCBpcyBub3QgYSBk ZWZhdWx0IGNhcGFiaWxpdHkgYXZhaWxhYmxlIHRvIGV4aXN0aW5nIHJlY2lwZXMKdGhhdCBpbmhl cml0IGNvcmUga2VybmVsIHN1cHBvcnQuCgpUaGUgcHJlcGFyYXRpb24gYW5kIGF1ZGl0IHBoYXNl cyBvZiBrZXJuZWwteW9jdG8gYWRkIHByb2Nlc3NpbmcgdGltZSBhbmQKc3RydWN0dXJlIHRvIGEg a2VybmVsIHRoYXQgaXMgbm90IGFsd2F5cyB3YW50ZWQsIGFzIHN1Y2gga2VybmVsCmNvbmZpZ3Vy YXRpb24gc3VwcG9ydCBoYXMgcmVtYWluZWQgb3V0c2lkZSBvZiB0aGUgY29yZSBrZXJuZWwgY2xh c3Nlcy4KCmtlcm5lbC15b2N0byBwcm9jZXNzaW5nIGhhcyBiZWVuIHNpbXBsaWZpZWQsIGFuZCBh cyBzdWNoLCBpdCBpcyBwb3NzaWJsZQp0byBtb3ZlIHRoZSBtYWlubGluZSBtZXJnaW5nIG9mIGtl cm5lbCBjb25maWd1cmF0aW9uIGZyYWdtZW50IGludG8gdGhlCmNvcmUga2VybmVsIGNsYXNzLCB3 aGlsZSBsZWF2aW5nIHRoZSBwcmVwYXJhdGlvbiBhbmQgYXVkaXQgb2Yga2VybmVsCmNvbmZpZ3Vy YXRpb24gZnJhZ21lbnRzIGluIGtlcm5lbC15b2N0by4gVGhpcyBtYWtlcyB0aGUgY29yZSBzdXBw b3J0CmF2YWlsYWJsZSB0byBhbnkga2VybmVsIHJlY2lwZS4KClRvIG1ha2UgdGhpcyBuZXcgY2Fw YWJpbGl0eSBhcyBsaWdodHdlaWdodCBhcyBwb3NzaWJsZSwgYSBuZXcgdGFzawpkb19tZXJnZV9j b25maWcoKSBpcyBjcmVhdGVkLCBhbmQgaXMgb25seSBlbmFibGVkIGlmIGNvbmZpZ3VyYXRpb24K ZnJhZ21lbnRzIGFyZSBkZXRlY3RlZCBpbiB0aGUgU1JDX1VSSS4KCmRvX21lcmdlX2NvbmZpZyBo YXMgdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzL3ZhcmlhYmxlczoKCiBLQ09ORklHX01PREU6IGNh biBiZSAnYWxsbm9jb25maWcnIG9yICdhbGxkZWZjb25maWcnIChkZWZhdWx0KQogICAgICAgICAg ICAgICBUaGUga2NvbmZpZyBtb2RlIGlzIHVzZWQgdG8gaW5zdHJ1Y3QgbWVyZ2VfY29uZmlnLnNo CiAgICAgICAgICAgICAgIG9uIGhvdyB1bnNwZWNpZmllZCBvcHRpb25zIHNob3VsZCBiZSBwb3B1 bGF0ZWQuCgogS0VSTkVMX0NPTkZJR1VSQVRJT05fRlJBR01FTlRTOiBsaXN0cyB0aGUgZnJhZ21l bnRzIHRoYXQgc2hvdWxkIGJlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lcmdl ZC4gVGhpcyBpcyBmaWxsZWQgaW4gYXV0b21hdGljYWxseQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBmb3IgYW55dGhpbmcgc3BlY2lmaWVkIG9uIHRoZSBTUkNfVVJJLgoKICR7V09S S0RJUn0va2VybmVsLWNmZ3M6IHRoaXMgZmlsZSBsaXN0cyBhZGRpdGlvbmFsIGZyYWdtZW50cyB0 aGF0CiAgICAgICAgICAgICAgICAgICAgICAgICBzaG91bGQgYmUgbWVyZ2VkLiBUaGlzIGV4aXN0 cyBzbyB0aGF0IHdyYXBwaW5nCiAgICAgICAgICAgICAgICAgICAgICAgICB0YXNrcyAobGlrZSBs aW51eC15b2N0bykgY2FuIHNwZWNpZnkgZnJhZ21lbnRzCiAgICAgICAgICAgICAgICAgICAgICAg ICB3aXRob3V0IG5lZWRpbmcgdG8gdXNlIGFub255bW91cyBweXRob24gYW5kCiAgICAgICAgICAg ICAgICAgICAgICAgICB2YXJpYWJsZSBvdmVycmlkZXMgKHdoaWNoIGFyZSBub3QgYWx3YXlzCiAg ICAgICAgICAgICAgICAgICAgICAgICBwb3NzaWJsZSkuCgpBbHNvIG5vdGUgdGhhdCBvbmNlIG1l cmdlX2NvbmZpZyBzdXBwb3J0IGlzIGVuYWJsZWQsIHRoZSBleGlzdGluZwpLRVJORUxfQ09ORklH X0NPTU1BTkQgaXMgb3ZlcnJpZGRlbiwgc2luY2UgbWVyZ2VfY29uZmlnIHRha2VzIGNhcmUgb2YK Y3JlYXRpbmcgdGhlIGZpbmFsIC5jb25maWcKCmxpbnV4LXlvY3RvIGlzIGFkYXB0ZWQgdG8gdXNl IHRoaXMgbmV3IHJvdXRpbmUsIGFuZCByZXN1bHRzIGluIHRoZQpzYW1lIGZpbmFsIC5jb25maWdz IGFzIHdlcmUgcHJldmlvdXNseSBnZW5lcmF0ZWQuCgpbWU9DVE8gIzgxOTFdCgpTaWduZWQtb2Zm LWJ5OiBCcnVjZSBBc2hmaWVsZCA8YnJ1Y2UuYXNoZmllbGRAd2luZHJpdmVyLmNvbT4KLS0tCiBt ZXRhL2NsYXNzZXMva2VybmVsLXlvY3RvLmJiY2xhc3MgfCAxNyArKysrKysrLS0tCiBtZXRhL2Ns YXNzZXMva2VybmVsLmJiY2xhc3MgICAgICAgfCA2NyArKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysKIDIgZmlsZXMgY2hhbmdlZCwgODAgaW5zZXJ0aW9ucygrKSwgNCBkZWxl dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9tZXRhL2NsYXNzZXMva2VybmVsLXlvY3RvLmJiY2xhc3Mg Yi9tZXRhL2NsYXNzZXMva2VybmVsLXlvY3RvLmJiY2xhc3MKaW5kZXggMWQ0NDc5NTFjNDlhLi5k ZjE0NzQwNDY5MzggMTAwNjQ0Ci0tLSBhL21ldGEvY2xhc3Nlcy9rZXJuZWwteW9jdG8uYmJjbGFz cworKysgYi9tZXRhL2NsYXNzZXMva2VybmVsLXlvY3RvLmJiY2xhc3MKQEAgLTI5MiwxNiArMjky LDI1IEBAIGRvX2tlcm5lbF9jb25maWdtZSgpIHsKIAkJYmJmYXRhbF9sb2cgIkNvdWxkIG5vdCBm aW5kIGNvbmZpZ3VyYXRpb24gcXVldWUgKCR7bWV0YV9kaXJ9L2NvbmZpZy5xdWV1ZSkiCiAJZmkK IAotCUNGTEFHUz0iJHtDRkxBR1N9ICR7VE9PTENIQUlOX09QVElPTlN9IglBUkNIPSR7QVJDSH0g bWVyZ2VfY29uZmlnLnNoIC1PICR7Qn0gJHtjb25maWdfZmxhZ3N9ICR7Y29uZmlnc30gPiAke21l dGFfZGlyfS9jZmcvbWVyZ2VfY29uZmlnX2J1aWxkLmxvZyAyPiYxCi0JaWYgWyAkPyAtbmUgMCBd OyB0aGVuCisJY29uZmlncz0kKGVjaG8gIiR7Y29uZmlnc30iIHwgc2VkICdzJS5rZXJuZWwtbWV0 YSUke1N9Ly5rZXJuZWwtbWV0YSVnJykKKwlpZiBbIC16ICIke2NvbmZpZ3N9IiBdOyB0aGVuCiAJ CWJiZmF0YWxfbG9nICJDb3VsZCBub3QgY29uZmlndXJlICR7S01BQ0hJTkV9LSR7TElOVVhfS0VS TkVMX1RZUEV9IgogCWZpCiAKLQllY2hvICIjIEdsb2JhbCBzZXR0aW5ncyBmcm9tIGxpbnV4IHJl Y2lwZSIgPj4gJHtCfS8uY29uZmlnCi0JZWNobyAiQ09ORklHX0xPQ0FMVkVSU0lPTj0iXCIke0xJ TlVYX1ZFUlNJT05fRVhURU5TSU9OfVwiID4+ICR7Qn0vLmNvbmZpZworCSMgcHV0IHRoZXNlIGlu IGEgcGxhY2Ugd2hlcmUgdGhlIG1lcmdlX2NvbmZpZyByb3V0aW5lIHdpbGwgZmluZCB0aGVtLCBh bmQgdXNlIHRoZW0KKwllY2hvICIke2NvbmZpZ3N9IiA+ICR7V09SS0RJUn0va2VybmVsLWNmZ3MK K30KKworZG9fc2V0X2xvY2FsdmVyc2lvbigpIHsKKyAgICBjZCAke1N9CisKKyAgICBlY2hvICIj IEdsb2JhbCBzZXR0aW5ncyBmcm9tIGxpbnV4IHJlY2lwZSIgPj4gJHtCfS8uY29uZmlnCisgICAg ZWNobyAiQ09ORklHX0xPQ0FMVkVSU0lPTj0iXCIke0xJTlVYX1ZFUlNJT05fRVhURU5TSU9OfVwi ID4+ICR7Qn0vLmNvbmZpZwogfQogCiBhZGR0YXNrIGtlcm5lbF9jb25maWdtZSBiZWZvcmUgZG9f Y29uZmlndXJlIGFmdGVyIGRvX3BhdGNoCithZGR0YXNrIG1lcmdlX2NvbmZpZyBiZWZvcmUgZG9f Y29uZmlndXJlIGFmdGVyIGRvX2tlcm5lbF9jb25maWdtZQorYWRkdGFzayBzZXRfbG9jYWx2ZXJz aW9uIGFmdGVyIGRvX2NvbmZpZ3VyZSBiZWZvcmUgZG9fY29tcGlsZQogCiBweXRob24gZG9fa2Vy bmVsX2NvbmZpZ2NoZWNrKCkgewogICAgIGltcG9ydCByZSwgc3RyaW5nLCBzeXMKZGlmZiAtLWdp dCBhL21ldGEvY2xhc3Nlcy9rZXJuZWwuYmJjbGFzcyBiL21ldGEvY2xhc3Nlcy9rZXJuZWwuYmJj bGFzcwppbmRleCAwMmE1ZTk2MWNiODYuLmUwODcwOTNhZTA1MyAxMDA2NDQKLS0tIGEvbWV0YS9j bGFzc2VzL2tlcm5lbC5iYmNsYXNzCisrKyBiL21ldGEvY2xhc3Nlcy9rZXJuZWwuYmJjbGFzcwpA QCAtNDc1LDYgKzQ3NSw3MyBAQCBweXRob24gY2hlY2tfb2xkZXN0X2tlcm5lbCgpIHsKIGNoZWNr X29sZGVzdF9rZXJuZWxbdmFyZGVwc2V4Y2x1ZGVdICs9ICJPTERFU1RfS0VSTkVMIEtFUk5FTF9W RVJTSU9OIgogZG9fY29uZmlndXJlW3ByZWZ1bmNzXSArPSAiY2hlY2tfb2xkZXN0X2tlcm5lbCIK IAorIyByZXR1cm5zIGFsbCB0aGUgZWxlbWVudHMgZnJvbSB0aGUgc3JjIHVyaSB0aGF0IGFyZSAu Y2ZnIG9yIGEgZGVmY29uZmlnCitkZWYgZ2V0X2NmZ19lbGVtZW50cyhkKToKKyAgICBzb3VyY2Vz PXNyY19wYXRjaGVzKGQsIFRydWUpCisgICAgc291cmNlc19saXN0PVtdCisgICAgZm9yIHMgaW4g c291cmNlczoKKyAgICAgICAgYmFzZSwgZXh0ID0gb3MucGF0aC5zcGxpdGV4dChvcy5wYXRoLmJh c2VuYW1lKHMpKQorICAgICAgICBpZiBleHQgYW5kIGV4dCBpbiBbIi5jZmciXToKKyAgICAgICAg ICAgIHNvdXJjZXNfbGlzdC5hcHBlbmQocykKKyAgICAgICAgZWxpZiBiYXNlIGFuZCBiYXNlIGlu ICdkZWZjb25maWcnOgorICAgICAgICAgICAgc291cmNlc19saXN0LmFwcGVuZChzKQorCisgICAg cmV0dXJuIHNvdXJjZXNfbGlzdAorCitweXRob24gKCkgeworICAgICAgIHNyY191cmlfZnJhZ3M9 Z2V0X2NmZ19lbGVtZW50cyhkKQorCisgICAgICAgIyBpZiB3ZSBmaW5kIGZyYWdtZW50cyBvbiB0 aGUgU1JDX1VSSToKKyAgICAgICAjICAgLSBlbmFibGUgdGhlIG1lcmdlX2NvbmZpZyB0YXNrCisg ICAgICAgIyAgIC0gZGlzYWJsZSB0aGUgb2xkIEtFUk5FTF9DT05GSUdfQ09NTUFORCAuLiBidXQg c2F2ZSBhIGNvcHkKKyAgICAgICBpZiBzcmNfdXJpX2ZyYWdzOgorICAgICAgICAgIGJiLmJ1aWxk LmFkZHRhc2soICJkb19tZXJnZV9jb25maWciLCAiZG9fY29uZmlndXJlIiwgTm9uZSwgZCApCisg ICAgICAgICAgZC5hcHBlbmRWYXIoICJLRVJORUxfQ09ORklHX0ZSQUdNRU5UUyIsICIgJXMiICUg JyAnLmpvaW4oc3JjX3VyaV9mcmFncykgKQorICAgICAgICAgIGQuc2V0VmFyKCAnS0VSTkVMX0NP TkZJR19DT01NQU5EX1NBVkUnLCBkLmdldFZhcignS0VSTkVMX0NPTkZJR19DT01NQU5EJykgKQor ICAgICAgICAgIGQuc2V0VmFyKCAnS0VSTkVMX0NPTkZJR19DT01NQU5EJywgJycgKQorICAgICAg ICAgIGJiLm5vdGUoIkVuYWJsaW5nIG1lcmdlIGNvbmZpZyBzdXBwb3J0IGZvcjogJXMiICUgZC5n ZXRWYXIoJ0tFUk5FTF9DT05GSUdfRlJBR01FTlRTJykpCit9CisKK2RvX21lcmdlX2NvbmZpZygp IHsKKyAgICAjIHRyYW5zbGF0ZSB0aGUga2NvbmZpZ19tb2RlIGludG8gc29tZXRoaW5nIHRoYXQg bWVyZ2VfY29uZmlnLnNoIHVuZGVyc3RhbmRzCisgICAgY29uZmlnX2ZsYWdzPSIiCisgICAgY2Fz ZSAke0tDT05GSUdfTU9ERX0gaW4KKwkqYWxsbm9jb25maWcpCisJICAgIGNvbmZpZ19mbGFncz0i LW4iCisJICAgIDs7CisJKmFsbGRlZmNvbmZpZykKKwkgICAgY29uZmlnX2ZsYWdzPSIiCisJICAg IDs7CisgICAgZXNhYworCisgICAgaWYgWyAtZiAiJHtXT1JLRElSfS9rZXJuZWwtY2ZncyIgXTsg dGhlbgorICAgICAgICBvbl9kaXNrX2ZyYWdzPSQoY2F0ICR7V09SS0RJUn0va2VybmVsLWNmZ3Mp CisgICAgZmkKKworICAgIGNvbmZpZ19mcmFnbWVudHM9IiIKKyAgICBmb3IgZnJhZyBpbiAke0tF Uk5FTF9DT05GSUdfRlJBR01FTlRTfSAke29uX2Rpc2tfZnJhZ3N9OyBkbworICAgICAgICBmdWxs X2ZyYWc9JHtmcmFnfQorICAgICAgICBpZiBbICEgLWYgJHtmcmFnfSBdOyB0aGVuCisgICAgICAg ICAgICBpZiBbICEgLWYgJHtXT1JLRElSfS8ke2ZyYWd9IF07IHRoZW4KKyAgICAgICAgICAgICAg ICBiYmZhdGFsX2xvZyAiZnJhZ21lbnQgJHtmcmFnfSB3YXMgc3BlY2lmaWVkLCBidXQgbm90IGZv dW5kIgorICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgIGZ1bGxfZnJhZz0iJHtXT1JL RElSfS8ke2ZyYWd9IgorICAgICAgICAgICAgZmkKKyAgICAgICAgZmkKKyAgICAgICAgY29uZmln X2ZyYWdtZW50cz0iJHtjb25maWdfZnJhZ21lbnRzfSAke2Z1bGxfZnJhZ30iCisgICAgZG9uZQor CisgICAgaWYgWyAtbiAiJHtjb25maWdfZnJhZ21lbnRzfSIgXTsgdGhlbgorICAgICAgICBjZCAk e1N9CisgICAgICAgIGVjaG8gIkNGTEFHUz0iJHtDRkxBR1N9ICR7VE9PTENIQUlOX09QVElPTlN9 IiBBUkNIPSR7QVJDSH0gbWVyZ2VfY29uZmlnLnNoIC1PICR7Qn0gJHtjb25maWdfZmxhZ3N9ICR7 Y29uZmlnX2ZyYWdtZW50c30iID4gJHtXT1JLRElSfS9tZXJnZV9jb25maWcubG9nIDI+JjEKKyAg ICAgICAgQ0ZMQUdTPSIke0NGTEFHU30gJHtUT09MQ0hBSU5fT1BUSU9OU30iIEFSQ0g9JHtBUkNI fSBtZXJnZV9jb25maWcuc2ggLU8gJHtCfSAke2NvbmZpZ19mbGFnc30gJHtjb25maWdfZnJhZ21l bnRzfSA+PiAke1dPUktESVJ9L21lcmdlX2NvbmZpZy5sb2cgMj4mMQorICAgICAgICBpZiBbICQ/ IC1uZSAwIF07IHRoZW4KKwkgICAgYmJmYXRhbF9sb2cgIkNvdWxkIG5vdCBtZXJnZSBjb25maWd1 cmF0aW9uIGZyYWdtZW50cywgc2VlICR7V09SS0RJUn0vbWVyZ2VfY29uZmlnLmxvZyBmb3IgZGV0 YWlscyAiCisgICAgICAgIGZpCisgICAgZmkKK30KK2RvX21lcmdlX2NvbmZpZ1tkZXBlbmRzXSA9 ICJrZXJuLXRvb2xzLW5hdGl2ZTpkb19wb3B1bGF0ZV9zeXNyb290IgorCiBrZXJuZWxfZG9fY29u ZmlndXJlKCkgewogCSMgZml4ZXMgZXh0cmEgKyBpbiAvbGliL21vZHVsZXMvMi42LjM3KwogCSMg JCBzY3JpcHRzL3NldGxvY2FsdmVyc2lvbiAuID0+ICsKLS0gCjIuNS4wCgo= 4649 2020-03-16 19:57:22 +0000 2020-03-16 19:57:22 +0000 Patch for fragments for all kernels v2. 0001-kernel-make-kernel-configuration-fragments-available.patch application/octet-stream 7509 bruce.ashfield RnJvbSA1NGE5MTVkZWYzZDhkZWU4NWZjZDQ5NmQxOTU4MmE1YjYzMjQ5YmU5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCcnVjZSBBc2hmaWVsZCA8YnJ1Y2UuYXNoZmllbGRAd2luZHJp dmVyLmNvbT4KRGF0ZTogTW9uLCAxNCBBdWcgMjAxNyAxMTo1NjoxNyAtMDQwMApTdWJqZWN0OiBb UEFUQ0hdIGtlcm5lbDogbWFrZSBrZXJuZWwgY29uZmlndXJhdGlvbiBmcmFnbWVudHMgYXZhaWxh YmxlIHdpdGhvdXQKIGtlcm5lbC15b2N0bwoKQWx0aG91Z2gga2VybmVsLXlvY3RvIGhhcyBhbHdh eXMgc3VwcG9ydGVkIGtlcm5lbCBjb25maWd1cmF0aW9uCmZyYWdtZW50cyBpdCBpcyBub3QgYSBk ZWZhdWx0IGNhcGFiaWxpdHkgYXZhaWxhYmxlIHRvIGV4aXN0aW5nIHJlY2lwZXMKdGhhdCBpbmhl cml0IGNvcmUga2VybmVsIHN1cHBvcnQuCgpUaGUgcHJlcGFyYXRpb24gYW5kIGF1ZGl0IHBoYXNl cyBvZiBrZXJuZWwteW9jdG8gYWRkIHByb2Nlc3NpbmcgdGltZSBhbmQKc3RydWN0dXJlIHRvIGEg a2VybmVsIHRoYXQgaXMgbm90IGFsd2F5cyB3YW50ZWQsIGFzIHN1Y2gga2VybmVsCmNvbmZpZ3Vy YXRpb24gc3VwcG9ydCBoYXMgcmVtYWluZWQgb3V0c2lkZSBvZiB0aGUgY29yZSBrZXJuZWwgY2xh c3Nlcy4KCmtlcm5lbC15b2N0byBwcm9jZXNzaW5nIGhhcyBiZWVuIHNpbXBsaWZpZWQsIGFuZCBh cyBzdWNoLCBpdCBpcyBwb3NzaWJsZQp0byBtb3ZlIHRoZSBtYWlubGluZSBtZXJnaW5nIG9mIGtl cm5lbCBjb25maWd1cmF0aW9uIGZyYWdtZW50IGludG8gdGhlCmNvcmUga2VybmVsIGNsYXNzLCB3 aGlsZSBsZWF2aW5nIHRoZSBwcmVwYXJhdGlvbiBhbmQgYXVkaXQgb2Yga2VybmVsCmNvbmZpZ3Vy YXRpb24gZnJhZ21lbnRzIGluIGtlcm5lbC15b2N0by4gVGhpcyBtYWtlcyB0aGUgY29yZSBzdXBw b3J0CmF2YWlsYWJsZSB0byBhbnkga2VybmVsIHJlY2lwZS4KClRvIG1ha2UgdGhpcyBuZXcgY2Fw YWJpbGl0eSBhcyBsaWdodHdlaWdodCBhcyBwb3NzaWJsZSwgYSBuZXcgdGFzawpkb19tZXJnZV9j b25maWcoKSBpcyBjcmVhdGVkLCBhbmQgaXMgb25seSBlbmFibGVkIGlmIGNvbmZpZ3VyYXRpb24K ZnJhZ21lbnRzIGFyZSBkZXRlY3RlZCBpbiB0aGUgU1JDX1VSSS4KCmRvX21lcmdlX2NvbmZpZyBo YXMgdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzL3ZhcmlhYmxlczoKCiBLQ09ORklHX01PREU6IGNh biBiZSAnYWxsbm9jb25maWcnIG9yICdhbGxkZWZjb25maWcnIChkZWZhdWx0KQogICAgICAgICAg ICAgICBUaGUga2NvbmZpZyBtb2RlIGlzIHVzZWQgdG8gaW5zdHJ1Y3QgbWVyZ2VfY29uZmlnLnNo CiAgICAgICAgICAgICAgIG9uIGhvdyB1bnNwZWNpZmllZCBvcHRpb25zIHNob3VsZCBiZSBwb3B1 bGF0ZWQuCgogS0VSTkVMX0NPTkZJR19GUkFHTUVOVFM6IGxpc3RzIHRoZSBmcmFnbWVudHMgdGhh dCBzaG91bGQgYmUKICAgICAgICAgICAgICAgICAgICAgICAgICBtZXJnZWQuIFRoaXMgaXMgZmls bGVkIGluIGF1dG9tYXRpY2FsbHkKICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgYW55dGhp bmcgc3BlY2lmaWVkIG9uIHRoZSBTUkNfVVJJLgoKICR7V09SS0RJUn0va2VybmVsLWNmZ3M6IHRo aXMgZmlsZSBsaXN0cyBhZGRpdGlvbmFsIGZyYWdtZW50cyB0aGF0CiAgICAgICAgICAgICAgICAg ICAgICAgICBzaG91bGQgYmUgbWVyZ2VkLiBUaGlzIGV4aXN0cyBzbyB0aGF0IHdyYXBwaW5nCiAg ICAgICAgICAgICAgICAgICAgICAgICB0YXNrcyAobGlrZSBsaW51eC15b2N0bykgY2FuIHNwZWNp ZnkgZnJhZ21lbnRzCiAgICAgICAgICAgICAgICAgICAgICAgICB3aXRob3V0IG5lZWRpbmcgdG8g dXNlIGFub255bW91cyBweXRob24gYW5kCiAgICAgICAgICAgICAgICAgICAgICAgICB2YXJpYWJs ZSBvdmVycmlkZXMgKHdoaWNoIGFyZSBub3QgYWx3YXlzCiAgICAgICAgICAgICAgICAgICAgICAg ICBwb3NzaWJsZSkuCgpBbHNvIG5vdGUgdGhhdCBvbmNlIG1lcmdlX2NvbmZpZyBzdXBwb3J0IGlz IGVuYWJsZWQsIHRoZSBleGlzdGluZwpLRVJORUxfQ09ORklHX0NPTU1BTkQgaXMgb3ZlcnJpZGRl biwgc2luY2UgbWVyZ2VfY29uZmlnIHRha2VzIGNhcmUgb2YKY3JlYXRpbmcgdGhlIGZpbmFsIC5j b25maWcKCmxpbnV4LXlvY3RvIGlzIGFkYXB0ZWQgdG8gdXNlIHRoaXMgbmV3IHJvdXRpbmUsIGFu ZCByZXN1bHRzIGluIHRoZQpzYW1lIGZpbmFsIC5jb25maWdzIGFzIHdlcmUgcHJldmlvdXNseSBn ZW5lcmF0ZWQuCgpbWU9DVE8gIzgxOTFdCgpTaWduZWQtb2ZmLWJ5OiBCcnVjZSBBc2hmaWVsZCA8 YnJ1Y2UuYXNoZmllbGRAd2luZHJpdmVyLmNvbT4KU2lnbmVkLW9mZi1ieTogQnJ1Y2UgQXNoZmll bGQgPGJydWNlLmFzaGZpZWxkQGdtYWlsLmNvbT4KLS0tCiBtZXRhL2NsYXNzZXMva2VybmVsLXlv Y3RvLmJiY2xhc3MgfCAxOSArKysrKy0tLS0KIG1ldGEvY2xhc3Nlcy9rZXJuZWwuYmJjbGFzcyAg ICAgICB8IDcwICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIDIgZmlsZXMgY2hhbmdl ZCwgODEgaW5zZXJ0aW9ucygrKSwgOCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9tZXRhL2Ns YXNzZXMva2VybmVsLXlvY3RvLmJiY2xhc3MgYi9tZXRhL2NsYXNzZXMva2VybmVsLXlvY3RvLmJi Y2xhc3MKaW5kZXggYmU1ZWNjYWZkNy4uYWRlY2Y3NjE1ZCAxMDA2NDQKLS0tIGEvbWV0YS9jbGFz c2VzL2tlcm5lbC15b2N0by5iYmNsYXNzCisrKyBiL21ldGEvY2xhc3Nlcy9rZXJuZWwteW9jdG8u YmJjbGFzcwpAQCAtMzkxLDE1ICszOTEsMTYgQEAgZG9fa2VybmVsX2NvbmZpZ21lKCkgewogCQli YmZhdGFsX2xvZyAiQ291bGQgbm90IGZpbmQgY29uZmlndXJhdGlvbiBxdWV1ZSAoJHttZXRhX2Rp cn0vY29uZmlnLnF1ZXVlKSIKIAlmaQogCi0JQ0ZMQUdTPSIke0NGTEFHU30gJHtUT09MQ0hBSU5f T1BUSU9OU30iIEhPU1RDQz0iJHtCVUlMRF9DQ30gJHtCVUlMRF9DRkxBR1N9ICR7QlVJTERfTERG TEFHU30iIEhPU1RDUFA9IiR7QlVJTERfQ1BQfSIgQ0M9IiR7S0VSTkVMX0NDfSIgTEQ9IiR7S0VS TkVMX0xEfSIgQVJDSD0ke0FSQ0h9IG1lcmdlX2NvbmZpZy5zaCAtTyAke0J9ICR7Y29uZmlnX2Zs YWdzfSAke2NvbmZpZ3N9ID4gJHttZXRhX2Rpcn0vY2ZnL21lcmdlX2NvbmZpZ19idWlsZC5sb2cg Mj4mMQotCWlmIFsgJD8gLW5lIDAgLW8gISAtZiAke0J9Ly5jb25maWcgXTsgdGhlbgotCQliYmVy cm9yICJDb3VsZCBub3QgZ2VuZXJhdGUgYSAuY29uZmlnIGZvciAke0tNQUNISU5FfS0ke0xJTlVY X0tFUk5FTF9UWVBFfSIKLQkJaWYgWyAke0tDT05GX0FVRElUX0xFVkVMfSAtZ3QgMSBdOyB0aGVu Ci0JCQliYmZhdGFsX2xvZyAiYGNhdCAke21ldGFfZGlyfS9jZmcvbWVyZ2VfY29uZmlnX2J1aWxk LmxvZ2AiCi0JCWVsc2UKLQkJCWJiZmF0YWxfbG9nICJEZXRhaWxzIGNhbiBiZSBmb3VuZCBhdDog JHtTfS8ke21ldGFfZGlyfS9jZmcvbWVyZ2VfY29uZmlnX2J1aWxkLmxvZyIKLQkJZmkKKwljb25m aWdzPSQoZWNobyAiJHtjb25maWdzfSIgfCBzZWQgJ3MlLmtlcm5lbC1tZXRhJSR7U30vLmtlcm5l bC1tZXRhJWcnKQorCWlmIFsgLXogIiR7Y29uZmlnc30iIF07IHRoZW4KKwkJYmJmYXRhbF9sb2cg Ik5vIGNvbmZpZ3VyYXRpb24gZnJhZ21lbnRzIG9yIGRlZmNvbmZpZyBmb3VuZCBmb3IgJHtLTUFD SElORX0tJHtMSU5VWF9LRVJORUxfVFlQRX0iCiAJZmkKKwkjIHB1dCB0aGVzZSBpbiBhIHBsYWNl IHdoZXJlIHRoZSBtZXJnZV9jb25maWcgcm91dGluZSB3aWxsIGZpbmQgdGhlbSwgYW5kIHVzZSB0 aGVtCisJZWNobyAiJHtjb25maWdzfSIgPiAke1dPUktESVJ9L2tlcm5lbC1jZmdzCit9CisKK2Rv X3NldF9sb2NhbHZlcnNpb24oKSB7CisJY2QgJHtTfQogCiAJaWYgWyAhIC16ICIke0xJTlVYX1ZF UlNJT05fRVhURU5TSU9OfSIgXTsgdGhlbgogCQllY2hvICIjIEdsb2JhbCBzZXR0aW5ncyBmcm9t IGxpbnV4IHJlY2lwZSIgPj4gJHtCfS8uY29uZmlnCkBAIC00MDgsNiArNDA5LDggQEAgZG9fa2Vy bmVsX2NvbmZpZ21lKCkgewogfQogCiBhZGR0YXNrIGtlcm5lbF9jb25maWdtZSBiZWZvcmUgZG9f Y29uZmlndXJlIGFmdGVyIGRvX3BhdGNoCithZGR0YXNrIG1lcmdlX2NvbmZpZyBiZWZvcmUgZG9f Y29uZmlndXJlIGFmdGVyIGRvX2tlcm5lbF9jb25maWdtZQorYWRkdGFzayBzZXRfbG9jYWx2ZXJz aW9uIGFmdGVyIGRvX2NvbmZpZ3VyZSBiZWZvcmUgZG9fY29tcGlsZQogCiBweXRob24gZG9fa2Vy bmVsX2NvbmZpZ2NoZWNrKCkgewogICAgIGltcG9ydCByZSwgc3RyaW5nLCBzeXMsIHN1YnByb2Nl c3MKZGlmZiAtLWdpdCBhL21ldGEvY2xhc3Nlcy9rZXJuZWwuYmJjbGFzcyBiL21ldGEvY2xhc3Nl cy9rZXJuZWwuYmJjbGFzcwppbmRleCAwZWFkZDNlZmI4Li5lNmU1NzlhZWQ1IDEwMDY0NAotLS0g YS9tZXRhL2NsYXNzZXMva2VybmVsLmJiY2xhc3MKKysrIGIvbWV0YS9jbGFzc2VzL2tlcm5lbC5i YmNsYXNzCkBAIC01MjQsNiArNTI0LDc2IEBAIHB5dGhvbiBjaGVja19vbGRlc3Rfa2VybmVsKCkg ewogY2hlY2tfb2xkZXN0X2tlcm5lbFt2YXJkZXBzZXhjbHVkZV0gKz0gIk9MREVTVF9LRVJORUwg S0VSTkVMX1ZFUlNJT04iCiBkb19jb25maWd1cmVbcHJlZnVuY3NdICs9ICJjaGVja19vbGRlc3Rf a2VybmVsIgogCisjIHJldHVybnMgYWxsIHRoZSBlbGVtZW50cyBmcm9tIHRoZSBzcmMgdXJpIHRo YXQgYXJlIC5jZmcgb3IgYSBkZWZjb25maWcKK2RlZiBnZXRfY2ZnX2VsZW1lbnRzKGQpOgorICAg IHNvdXJjZXM9c3JjX3BhdGNoZXMoZCwgVHJ1ZSkKKyAgICBzb3VyY2VzX2xpc3Q9W10KKyAgICBm b3IgcyBpbiBzb3VyY2VzOgorICAgICAgICBiYXNlLCBleHQgPSBvcy5wYXRoLnNwbGl0ZXh0KG9z LnBhdGguYmFzZW5hbWUocykpCisgICAgICAgIGlmIGV4dCBhbmQgZXh0IGluIFsiLmNmZyJdOgor ICAgICAgICAgICAgc291cmNlc19saXN0LmFwcGVuZChzKQorICAgICAgICBlbGlmIGJhc2UgYW5k ICdkZWZjb25maWcnIGluIGJhc2U6CisgICAgICAgICAgICBzb3VyY2VzX2xpc3QuYXBwZW5kKHMp CisKKyAgICByZXR1cm4gc291cmNlc19saXN0CisKK3B5dGhvbiAoKSB7CisgICAgICAgc3JjX3Vy aV9mcmFncz1nZXRfY2ZnX2VsZW1lbnRzKGQpCisKKyAgICAgICAjIGlmIHdlIGZpbmQgZnJhZ21l bnRzIG9uIHRoZSBTUkNfVVJJOgorICAgICAgICMgICAtIGVuYWJsZSB0aGUgbWVyZ2VfY29uZmln IHRhc2sKKyAgICAgICAjICAgLSBkaXNhYmxlIHRoZSBvbGQgS0VSTkVMX0NPTkZJR19DT01NQU5E IC4uIGJ1dCBzYXZlIGEgY29weQorICAgICAgIGlmIHNyY191cmlfZnJhZ3M6CisgICAgICAgICAg YmIuYnVpbGQuYWRkdGFzayggImRvX21lcmdlX2NvbmZpZyIsICJkb19jb25maWd1cmUiLCBOb25l LCBkICkKKyAgICAgICAgICBkLmFwcGVuZFZhciggIktFUk5FTF9DT05GSUdfRlJBR01FTlRTIiwg IiAlcyIgJSAnICcuam9pbihzcmNfdXJpX2ZyYWdzKSApCisgICAgICAgICAgZC5zZXRWYXIoICdL RVJORUxfQ09ORklHX0NPTU1BTkRfU0FWRScsIGQuZ2V0VmFyKCdLRVJORUxfQ09ORklHX0NPTU1B TkQnKSApCisgICAgICAgICAgZC5zZXRWYXIoICdLRVJORUxfQ09ORklHX0NPTU1BTkQnLCAnJyAp CisgICAgICAgICAgYmIubm90ZSgiRW5hYmxpbmcgbWVyZ2UgY29uZmlnIHN1cHBvcnQgZm9yOiAl cyIgJSBkLmdldFZhcignS0VSTkVMX0NPTkZJR19GUkFHTUVOVFMnKSkKK30KKworZG9fbWVyZ2Vf Y29uZmlnKCkgeworICAgIHNldCArZQorCisgICAgIyB0cmFuc2xhdGUgdGhlIGtjb25maWdfbW9k ZSBpbnRvIHNvbWV0aGluZyB0aGF0IG1lcmdlX2NvbmZpZy5zaCB1bmRlcnN0YW5kcworICAgIGNv bmZpZ19mbGFncz0iIgorICAgIGNhc2UgJHtLQ09ORklHX01PREV9IGluCisJKmFsbG5vY29uZmln KQorCSAgICBjb25maWdfZmxhZ3M9Ii1uIgorCSAgICA7OworCSphbGxkZWZjb25maWcpCisJICAg IGNvbmZpZ19mbGFncz0iIgorCSAgICA7OworICAgIGVzYWMKKworICAgIGlmIFsgLWYgIiR7V09S S0RJUn0va2VybmVsLWNmZ3MiIF07IHRoZW4KKyAgICAgICAgb25fZGlza19mcmFncz0kKGNhdCAk e1dPUktESVJ9L2tlcm5lbC1jZmdzKQorICAgIGZpCisKKyAgICBjb25maWdfZnJhZ21lbnRzPSIi CisgICAgZm9yIGZyYWcgaW4gJHtLRVJORUxfQ09ORklHX0ZSQUdNRU5UU30gJHtvbl9kaXNrX2Zy YWdzfTsgZG8KKyAgICAgICAgZnVsbF9mcmFnPSR7ZnJhZ30KKyAgICAgICAgaWYgWyAhIC1mICR7 ZnJhZ30gXTsgdGhlbgorICAgICAgICAgICAgaWYgWyAhIC1mICR7V09SS0RJUn0vJHtmcmFnfSBd OyB0aGVuCisgICAgICAgICAgICAgICAgYmJmYXRhbF9sb2cgImZyYWdtZW50ICR7ZnJhZ30gd2Fz IHNwZWNpZmllZCwgYnV0IG5vdCBmb3VuZCIKKyAgICAgICAgICAgIGVsc2UKKyAgICAgICAgICAg ICAgICBmdWxsX2ZyYWc9IiR7V09SS0RJUn0vJHtmcmFnfSIKKyAgICAgICAgICAgIGZpCisgICAg ICAgIGZpCisgICAgICAgIGNvbmZpZ19mcmFnbWVudHM9IiR7Y29uZmlnX2ZyYWdtZW50c30gJHtm dWxsX2ZyYWd9IgorICAgIGRvbmUKKworICAgIGlmIFsgLW4gIiR7Y29uZmlnX2ZyYWdtZW50c30i IF07IHRoZW4KKyAgICAgICAgY2QgJHtTfQorICAgICAgICBlY2hvICJDRkxBR1M9XCIke0NGTEFH U30gJHtUT09MQ0hBSU5fT1BUSU9OU31cIiBIT1NUQ0M9XCIke0JVSUxEX0NDfSAke0JVSUxEX0NG TEFHU30gJHtCVUlMRF9MREZMQUdTfVwiIEhPU1RDUFA9XCIke0JVSUxEX0NQUH1cIiBDQz1cIiR7 S0VSTkVMX0NDfVwiIExEPVwiJHtLRVJORUxfTER9XCIgQVJDSD0ke0FSQ0h9IG1lcmdlX2NvbmZp Zy5zaCAtTyAke0J9ICR7Y29uZmlnX2ZsYWdzfSAke2NvbmZpZ19mcmFnbWVudHN9IiA+ICR7V09S S0RJUn0vbWVyZ2VfY29uZmlnLmxvZyAyPiYxCisJQ0ZMQUdTPSIke0NGTEFHU30gJHtUT09MQ0hB SU5fT1BUSU9OU30iIEhPU1RDQz0iJHtCVUlMRF9DQ30gJHtCVUlMRF9DRkxBR1N9ICR7QlVJTERf TERGTEFHU30iIEhPU1RDUFA9IiR7QlVJTERfQ1BQfSIgQ0M9IiR7S0VSTkVMX0NDfSIgTEQ9IiR7 S0VSTkVMX0xEfSIgQVJDSD0ke0FSQ0h9IG1lcmdlX2NvbmZpZy5zaCAtTyAke0J9ICR7Y29uZmln X2ZsYWdzfSAke2NvbmZpZ19mcmFnbWVudHN9ID4+ICR7V09SS0RJUn0vbWVyZ2VfY29uZmlnLmxv ZyAyPiYxCisJaWYgWyAkPyAtbmUgMCAtbyAhIC1mICR7Qn0vLmNvbmZpZyBdOyB0aGVuCisJCWJi ZXJyb3IgIkNvdWxkIG5vdCBnZW5lcmF0ZSBhIC5jb25maWcgZm9yICR7S01BQ0hJTkV9LSR7TElO VVhfS0VSTkVMX1RZUEV9IgorCQliYmZhdGFsX2xvZyAiYGNhdCAke1dPUktESVJ9L21lcmdlX2Nv bmZpZy5sb2dgIgorCWZpCisgICAgZmkKK30KK2RvX21lcmdlX2NvbmZpZ1tkZXBlbmRzXSA9ICJr ZXJuLXRvb2xzLW5hdGl2ZTpkb19wb3B1bGF0ZV9zeXNyb290IgorCiBrZXJuZWxfZG9fY29uZmln dXJlKCkgewogCSMgZml4ZXMgZXh0cmEgKyBpbiAvbGliL21vZHVsZXMvMi42LjM3KwogCSMgJCBz Y3JpcHRzL3NldGxvY2FsdmVyc2lvbiAuID0+ICsKLS0gCjIuMTkuMQoK