From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 884B17D910 for ; Thu, 18 Jul 2019 17:50:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727623AbfGRRu0 (ORCPT ); Thu, 18 Jul 2019 13:50:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:35110 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726715AbfGRRuZ (ORCPT ); Thu, 18 Jul 2019 13:50:25 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C3EC421019; Thu, 18 Jul 2019 17:50:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563472224; bh=6tSD0Suq+WYw0e1Of1mjiPhBMB1Sm91MrrAFE36jpOc=; h=In-Reply-To:References:Subject:To:Cc:From:Date:From; b=qhh1Yzvu9wkDER9y45leq7ittg2ChvzEFbwwLVZc06ECTh2DoTQNSKaogbtmfkT68 1l2DbFS/qt/oI4MDEM0RfDRSnGQfBEZtVR9UZ8zb3LGf5E0Nrh56Y4ypa4K4xT9cYG u2MA/NXEj9SHiUe3C8HpY4EmJNMMPRP3PJB9AiWI= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20190712081744.87097-1-brendanhiggins@google.com> <20190712081744.87097-5-brendanhiggins@google.com> <20190715221554.8417320665@mail.kernel.org> <20190716175021.9CA412173C@mail.kernel.org> Subject: Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger To: Brendan Higgins Cc: Frank Rowand , Greg KH , Josh Poimboeuf , Kees Cook , Kieran Bingham , Luis Chamberlain , Peter Zijlstra , Rob Herring , shuah , Theodore Ts'o , Masahiro Yamada , devicetree , dri-devel , kunit-dev@googlegroups.com, "open list:DOCUMENTATION" , linux-fsdevel@vger.kernel.org, linux-kbuild , Linux Kernel Mailing List , "open list:KERNEL SELFTEST FRAMEWORK" , linux-nvdimm , linux-um@lists.infradead.org, Sasha Levin , "Bird, Timothy" , Amir Goldstein , Dan Carpenter , Daniel Vetter , Jeff Dike , Joel Stanley , Julia Lawall , Kevin Hilman , Knut Omang , Logan Gunthorpe , Michael Ellerman , Petr Mladek , Randy Dunlap , Richard Weinberger , David Rientjes , Steven Rostedt , wfg@linux.intel.com From: Stephen Boyd User-Agent: alot/0.8.1 Date: Thu, 18 Jul 2019 10:50:23 -0700 Message-Id: <20190718175024.C3EC421019@mail.kernel.org> Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Quoting Brendan Higgins (2019-07-16 11:52:01) > On Tue, Jul 16, 2019 at 10:50 AM Stephen Boyd wrote: > > >=20 > > The only hypothetical case where this can't be done is a complicated > > assertion or expectation that does more than one check and can't be > > written as a function that dumps out what went wrong. Is this a real > > problem? Maybe such an assertion should just open code that logic so we > > don't have to build up a string for all the other simple cases. >=20 > I have some expectations in follow up patchsets for which I created a > set of composable matchers for matching structures and function calls > that by their nature cannot be written as a single function. The > matcher thing is a bit speculative, I know, but for any kind of > function call matching, you need to store a record of functions you > are expecting to have called and then each one needs to have a set of > expectations defined by the user; I don't think there is a way to do > that that doesn't involve having multiple separate functions each > having some information useful to constructing the message. >=20 > I know the code in question isn't in this patchset; the function > matching code was in one of the earlier versions of the RFC, but I > dropped it to make this patchset smaller and more manageable. So I get > it if you would like me to drop it and add it back in when I try to > get the function and structure matching stuff in, but I would really > prefer to keep it as is if you don't care too much. Do you have a link to those earlier patches? >=20 > > It seems far simpler to get rid of the string stream API and just have a > > struct for this. > > > > struct kunit_fail_msg { > > const char *line; > > const char *file; > > const char *func; > > const char *msg; > > }; > > > > Then you can have the assertion macros create this on the stack (with > > another macro?). > > > > #define DEFINE_KUNIT_FAIL_MSG(name, _msg) \ > > struct kunit_fail_msg name =3D { \ > > .line =3D __LINE__, \ > > .file =3D __FILE__, \ > > .func =3D __func__, \ > > .msg =3D _msg, \ > > } > > > > I don't want to derail this whole series on this topic, but it seems > > like a bunch of code is there to construct this same set of information > > over and over again into a buffer a little bit at a time and then throw > > it away when nothing fails just because we may want to support the case > > where we have some unstructured data to inform the user about. >=20 > Yeah, that's fair. I think there are a number of improvements to be > made with how the expectations are defined other than that, but I was > hoping I could do that after this patchset is merged. I just figured > with the kinds of things I would like to do, it would lead to a whole > new round of discussion. >=20 > In either case, I think I would still like to use the `struct > kunit_stream` as part of the interface to share the failure message > with the test case runner code in test.c, at least eventually, so that > I only have to have one way to receive data from expectations, but I > think I can do that and still do what you suggest by just constructing > the kunit_stream at the end of expectations where it is feasible. >=20 > All in all I agree with what you are saying, but I would rather do it > as a follow up possibly once we have some more code on the table. I > could just see this opening up a whole new can of worms where we > debate about exactly how expectations and assertions work for another > several months, only to rip it all out shortly there after. I know > that's how these things go, but that's my preference. >=20 > I can do what you suggest if you feel strongly about it, but I would > prefer to hold off until later. It's your call. >=20 The crux of my complaint is that the string stream API is too loosely defined to be usable. It allows tests to build up a string of unstructured information, but with certain calling constraints so we have to tread carefully. If there was more structure to the data that's being recorded then the test case runner could operate on the data without having to do string/stream operations, allocations, etc. This would make the assertion logic much more concrete and specific to kunit, instead of this small kunit wrapper that's been placed on top of string stream. TL;DR: If we can get rid of the string stream API I'd view that as an improvement because building arbitrary strings in the kernel is complex, error prone and has calling context concerns. Is the intention that other code besides unit tests will use this string stream API to build up strings? Any targets in mind? This would be a good way to get the API merged upstream given that its 2019 and we haven't had such an API in the kernel so far. An "object oriented" (strong quotes!) approach where kunit_fail_msg is the innermost struct in some assertion specific structure might work nicely and allow the test runner to call a generic 'format' function to print out the message based on the type of assertion/expectation it is. It probably would mean less code size too because the strings that are common will be in the common printing function instead of created twice, in the macros/code and then copied to the heap for the string stream. struct kunit_assert { const char *line; const char *file; const char *func; void (*format)(struct kunit_assert *assert); }; struct kunit_comparison_assert { enum operator operator; const char *left; const char *right; struct kunit_assert assert; }; struct kunit_bool_assert { const char *truth; const char *statement; struct kunit_assert assert; }; void kunit_format_comparison(struct kunit_assert *assert) { struct kunit_comparison_assert *comp =3D container_of(assert, ...) kunit_printk(...) } Maybe other people have opinions here on if you should do it now or later. Future coding is not a great argument because it's hard to predict the future. On the other hand, this patchset is in good shape to merge and I'd like to use it to write unit tests for code I maintain so I don't want to see this stall out. Sorry if I'm opening the can of worms you're talking about. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 89AB92194EB76 for ; Thu, 18 Jul 2019 10:52:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20190712081744.87097-1-brendanhiggins@google.com> <20190712081744.87097-5-brendanhiggins@google.com> <20190715221554.8417320665@mail.kernel.org> <20190716175021.9CA412173C@mail.kernel.org> Subject: Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger From: Stephen Boyd Date: Thu, 18 Jul 2019 10:50:23 -0700 Message-Id: <20190718175024.C3EC421019@mail.kernel.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Brendan Higgins Cc: Petr Mladek , "open list:DOCUMENTATION" , Peter Zijlstra , Amir Goldstein , dri-devel , Sasha Levin , Masahiro Yamada , Michael Ellerman , "open list:KERNEL SELFTEST FRAMEWORK" , shuah , Rob Herring , linux-nvdimm , Frank Rowand , Knut Omang , Kieran Bingham , wfg@linux.intel.com, Joel Stanley , David Rientjes , Jeff Dike , Dan Carpenter , devicetree , linux-kbuild , "Bird, Timothy , linux-um@lists.infradead.org, Steven Rostedt" , Julia Lawall , Josh Poimboeuf , kunit-dev@googlegroups.com, Theodore Ts'o , Richard Weinberger , Greg KH , Randy Dunlap , Linux Kernel Mailing List , Luis Chamberlain , Daniel Vetter , Kees Cook , linux-fsdevel@vger.kernel.org, Kevin Hilman List-ID: Quoting Brendan Higgins (2019-07-16 11:52:01) > On Tue, Jul 16, 2019 at 10:50 AM Stephen Boyd wrote: > > > > > The only hypothetical case where this can't be done is a complicated > > assertion or expectation that does more than one check and can't be > > written as a function that dumps out what went wrong. Is this a real > > problem? Maybe such an assertion should just open code that logic so we > > don't have to build up a string for all the other simple cases. > > I have some expectations in follow up patchsets for which I created a > set of composable matchers for matching structures and function calls > that by their nature cannot be written as a single function. The > matcher thing is a bit speculative, I know, but for any kind of > function call matching, you need to store a record of functions you > are expecting to have called and then each one needs to have a set of > expectations defined by the user; I don't think there is a way to do > that that doesn't involve having multiple separate functions each > having some information useful to constructing the message. > > I know the code in question isn't in this patchset; the function > matching code was in one of the earlier versions of the RFC, but I > dropped it to make this patchset smaller and more manageable. So I get > it if you would like me to drop it and add it back in when I try to > get the function and structure matching stuff in, but I would really > prefer to keep it as is if you don't care too much. Do you have a link to those earlier patches? > > > It seems far simpler to get rid of the string stream API and just have a > > struct for this. > > > > struct kunit_fail_msg { > > const char *line; > > const char *file; > > const char *func; > > const char *msg; > > }; > > > > Then you can have the assertion macros create this on the stack (with > > another macro?). > > > > #define DEFINE_KUNIT_FAIL_MSG(name, _msg) \ > > struct kunit_fail_msg name = { \ > > .line = __LINE__, \ > > .file = __FILE__, \ > > .func = __func__, \ > > .msg = _msg, \ > > } > > > > I don't want to derail this whole series on this topic, but it seems > > like a bunch of code is there to construct this same set of information > > over and over again into a buffer a little bit at a time and then throw > > it away when nothing fails just because we may want to support the case > > where we have some unstructured data to inform the user about. > > Yeah, that's fair. I think there are a number of improvements to be > made with how the expectations are defined other than that, but I was > hoping I could do that after this patchset is merged. I just figured > with the kinds of things I would like to do, it would lead to a whole > new round of discussion. > > In either case, I think I would still like to use the `struct > kunit_stream` as part of the interface to share the failure message > with the test case runner code in test.c, at least eventually, so that > I only have to have one way to receive data from expectations, but I > think I can do that and still do what you suggest by just constructing > the kunit_stream at the end of expectations where it is feasible. > > All in all I agree with what you are saying, but I would rather do it > as a follow up possibly once we have some more code on the table. I > could just see this opening up a whole new can of worms where we > debate about exactly how expectations and assertions work for another > several months, only to rip it all out shortly there after. I know > that's how these things go, but that's my preference. > > I can do what you suggest if you feel strongly about it, but I would > prefer to hold off until later. It's your call. > The crux of my complaint is that the string stream API is too loosely defined to be usable. It allows tests to build up a string of unstructured information, but with certain calling constraints so we have to tread carefully. If there was more structure to the data that's being recorded then the test case runner could operate on the data without having to do string/stream operations, allocations, etc. This would make the assertion logic much more concrete and specific to kunit, instead of this small kunit wrapper that's been placed on top of string stream. TL;DR: If we can get rid of the string stream API I'd view that as an improvement because building arbitrary strings in the kernel is complex, error prone and has calling context concerns. Is the intention that other code besides unit tests will use this string stream API to build up strings? Any targets in mind? This would be a good way to get the API merged upstream given that its 2019 and we haven't had such an API in the kernel so far. An "object oriented" (strong quotes!) approach where kunit_fail_msg is the innermost struct in some assertion specific structure might work nicely and allow the test runner to call a generic 'format' function to print out the message based on the type of assertion/expectation it is. It probably would mean less code size too because the strings that are common will be in the common printing function instead of created twice, in the macros/code and then copied to the heap for the string stream. struct kunit_assert { const char *line; const char *file; const char *func; void (*format)(struct kunit_assert *assert); }; struct kunit_comparison_assert { enum operator operator; const char *left; const char *right; struct kunit_assert assert; }; struct kunit_bool_assert { const char *truth; const char *statement; struct kunit_assert assert; }; void kunit_format_comparison(struct kunit_assert *assert) { struct kunit_comparison_assert *comp = container_of(assert, ...) kunit_printk(...) } Maybe other people have opinions here on if you should do it now or later. Future coding is not a great argument because it's hard to predict the future. On the other hand, this patchset is in good shape to merge and I'd like to use it to write unit tests for code I maintain so I don't want to see this stall out. Sorry if I'm opening the can of worms you're talking about. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hoAXx-0006g3-KR for linux-um@lists.infradead.org; Thu, 18 Jul 2019 17:50:27 +0000 MIME-Version: 1.0 In-Reply-To: References: <20190712081744.87097-1-brendanhiggins@google.com> <20190712081744.87097-5-brendanhiggins@google.com> <20190715221554.8417320665@mail.kernel.org> <20190716175021.9CA412173C@mail.kernel.org> Subject: Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger From: Stephen Boyd Date: Thu, 18 Jul 2019 10:50:23 -0700 Message-Id: <20190718175024.C3EC421019@mail.kernel.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Brendan Higgins Cc: Petr Mladek , "open list:DOCUMENTATION" , Peter Zijlstra , Amir Goldstein , dri-devel , Sasha Levin , Masahiro Yamada , Michael Ellerman , "open list:KERNEL SELFTEST FRAMEWORK" , shuah , Rob Herring , linux-nvdimm , Frank Rowand , Knut Omang , Kieran Bingham , wfg@linux.intel.com, Joel Stanley , David Rientjes , Jeff Dike , Dan Carpenter , devicetree , linux-kbuild , "Bird, Timothy , linux-um@lists.infradead.org, Steven Rostedt" , Julia Lawall , Josh Poimboeuf , kunit-dev@googlegroups.com, Theodore Ts'o , Richard Weinberger , Greg KH , Randy Dunlap , Linux Kernel Mailing List , Luis Chamberlain , Daniel Vetter , Kees Cook , linux-fsdevel@vger.kernel.org, Logan Gunthorpe , Kevin Hilman Quoting Brendan Higgins (2019-07-16 11:52:01) > On Tue, Jul 16, 2019 at 10:50 AM Stephen Boyd wrote: > > > > > The only hypothetical case where this can't be done is a complicated > > assertion or expectation that does more than one check and can't be > > written as a function that dumps out what went wrong. Is this a real > > problem? Maybe such an assertion should just open code that logic so we > > don't have to build up a string for all the other simple cases. > > I have some expectations in follow up patchsets for which I created a > set of composable matchers for matching structures and function calls > that by their nature cannot be written as a single function. The > matcher thing is a bit speculative, I know, but for any kind of > function call matching, you need to store a record of functions you > are expecting to have called and then each one needs to have a set of > expectations defined by the user; I don't think there is a way to do > that that doesn't involve having multiple separate functions each > having some information useful to constructing the message. > > I know the code in question isn't in this patchset; the function > matching code was in one of the earlier versions of the RFC, but I > dropped it to make this patchset smaller and more manageable. So I get > it if you would like me to drop it and add it back in when I try to > get the function and structure matching stuff in, but I would really > prefer to keep it as is if you don't care too much. Do you have a link to those earlier patches? > > > It seems far simpler to get rid of the string stream API and just have a > > struct for this. > > > > struct kunit_fail_msg { > > const char *line; > > const char *file; > > const char *func; > > const char *msg; > > }; > > > > Then you can have the assertion macros create this on the stack (with > > another macro?). > > > > #define DEFINE_KUNIT_FAIL_MSG(name, _msg) \ > > struct kunit_fail_msg name = { \ > > .line = __LINE__, \ > > .file = __FILE__, \ > > .func = __func__, \ > > .msg = _msg, \ > > } > > > > I don't want to derail this whole series on this topic, but it seems > > like a bunch of code is there to construct this same set of information > > over and over again into a buffer a little bit at a time and then throw > > it away when nothing fails just because we may want to support the case > > where we have some unstructured data to inform the user about. > > Yeah, that's fair. I think there are a number of improvements to be > made with how the expectations are defined other than that, but I was > hoping I could do that after this patchset is merged. I just figured > with the kinds of things I would like to do, it would lead to a whole > new round of discussion. > > In either case, I think I would still like to use the `struct > kunit_stream` as part of the interface to share the failure message > with the test case runner code in test.c, at least eventually, so that > I only have to have one way to receive data from expectations, but I > think I can do that and still do what you suggest by just constructing > the kunit_stream at the end of expectations where it is feasible. > > All in all I agree with what you are saying, but I would rather do it > as a follow up possibly once we have some more code on the table. I > could just see this opening up a whole new can of worms where we > debate about exactly how expectations and assertions work for another > several months, only to rip it all out shortly there after. I know > that's how these things go, but that's my preference. > > I can do what you suggest if you feel strongly about it, but I would > prefer to hold off until later. It's your call. > The crux of my complaint is that the string stream API is too loosely defined to be usable. It allows tests to build up a string of unstructured information, but with certain calling constraints so we have to tread carefully. If there was more structure to the data that's being recorded then the test case runner could operate on the data without having to do string/stream operations, allocations, etc. This would make the assertion logic much more concrete and specific to kunit, instead of this small kunit wrapper that's been placed on top of string stream. TL;DR: If we can get rid of the string stream API I'd view that as an improvement because building arbitrary strings in the kernel is complex, error prone and has calling context concerns. Is the intention that other code besides unit tests will use this string stream API to build up strings? Any targets in mind? This would be a good way to get the API merged upstream given that its 2019 and we haven't had such an API in the kernel so far. An "object oriented" (strong quotes!) approach where kunit_fail_msg is the innermost struct in some assertion specific structure might work nicely and allow the test runner to call a generic 'format' function to print out the message based on the type of assertion/expectation it is. It probably would mean less code size too because the strings that are common will be in the common printing function instead of created twice, in the macros/code and then copied to the heap for the string stream. struct kunit_assert { const char *line; const char *file; const char *func; void (*format)(struct kunit_assert *assert); }; struct kunit_comparison_assert { enum operator operator; const char *left; const char *right; struct kunit_assert assert; }; struct kunit_bool_assert { const char *truth; const char *statement; struct kunit_assert assert; }; void kunit_format_comparison(struct kunit_assert *assert) { struct kunit_comparison_assert *comp = container_of(assert, ...) kunit_printk(...) } Maybe other people have opinions here on if you should do it now or later. Future coding is not a great argument because it's hard to predict the future. On the other hand, this patchset is in good shape to merge and I'd like to use it to write unit tests for code I maintain so I don't want to see this stall out. Sorry if I'm opening the can of worms you're talking about. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger Date: Thu, 18 Jul 2019 10:50:23 -0700 Message-ID: <20190718175024.C3EC421019@mail.kernel.org> References: <20190712081744.87097-1-brendanhiggins@google.com> <20190712081744.87097-5-brendanhiggins@google.com> <20190715221554.8417320665@mail.kernel.org> <20190716175021.9CA412173C@mail.kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Brendan Higgins Cc: Petr Mladek , "open list:DOCUMENTATION" , Peter Zijlstra , Amir Goldstein , dri-devel , Sasha Levin , Masahiro Yamada , Michael Ellerman , "open list:KERNEL SELFTEST FRAMEWORK" , shuah , linux-nvdimm , Frank Rowand , Knut Omang , Kieran Bingham , wfg@linux.intel.com, Joel Stanley , David Rientjes , Jeff Dike , Dan Carpenter , devicetree , linux-kbuild , "Bird, Timothy" List-Id: devicetree@vger.kernel.org UXVvdGluZyBCcmVuZGFuIEhpZ2dpbnMgKDIwMTktMDctMTYgMTE6NTI6MDEpCj4gT24gVHVlLCBK dWwgMTYsIDIwMTkgYXQgMTA6NTAgQU0gU3RlcGhlbiBCb3lkIDxzYm95ZEBrZXJuZWwub3JnPiB3 cm90ZToKPiA+Cj4gCj4gPiBUaGUgb25seSBoeXBvdGhldGljYWwgY2FzZSB3aGVyZSB0aGlzIGNh bid0IGJlIGRvbmUgaXMgYSBjb21wbGljYXRlZAo+ID4gYXNzZXJ0aW9uIG9yIGV4cGVjdGF0aW9u IHRoYXQgZG9lcyBtb3JlIHRoYW4gb25lIGNoZWNrIGFuZCBjYW4ndCBiZQo+ID4gd3JpdHRlbiBh cyBhIGZ1bmN0aW9uIHRoYXQgZHVtcHMgb3V0IHdoYXQgd2VudCB3cm9uZy4gSXMgdGhpcyBhIHJl YWwKPiA+IHByb2JsZW0/IE1heWJlIHN1Y2ggYW4gYXNzZXJ0aW9uIHNob3VsZCBqdXN0IG9wZW4g Y29kZSB0aGF0IGxvZ2ljIHNvIHdlCj4gPiBkb24ndCBoYXZlIHRvIGJ1aWxkIHVwIGEgc3RyaW5n IGZvciBhbGwgdGhlIG90aGVyIHNpbXBsZSBjYXNlcy4KPiAKPiBJIGhhdmUgc29tZSBleHBlY3Rh dGlvbnMgaW4gZm9sbG93IHVwIHBhdGNoc2V0cyBmb3Igd2hpY2ggSSBjcmVhdGVkIGEKPiBzZXQg b2YgY29tcG9zYWJsZSBtYXRjaGVycyBmb3IgbWF0Y2hpbmcgc3RydWN0dXJlcyBhbmQgZnVuY3Rp b24gY2FsbHMKPiB0aGF0IGJ5IHRoZWlyIG5hdHVyZSBjYW5ub3QgYmUgd3JpdHRlbiBhcyBhIHNp bmdsZSBmdW5jdGlvbi4gVGhlCj4gbWF0Y2hlciB0aGluZyBpcyBhIGJpdCBzcGVjdWxhdGl2ZSwg SSBrbm93LCBidXQgZm9yIGFueSBraW5kIG9mCj4gZnVuY3Rpb24gY2FsbCBtYXRjaGluZywgeW91 IG5lZWQgdG8gc3RvcmUgYSByZWNvcmQgb2YgZnVuY3Rpb25zIHlvdQo+IGFyZSBleHBlY3Rpbmcg dG8gaGF2ZSBjYWxsZWQgYW5kIHRoZW4gZWFjaCBvbmUgbmVlZHMgdG8gaGF2ZSBhIHNldCBvZgo+ IGV4cGVjdGF0aW9ucyBkZWZpbmVkIGJ5IHRoZSB1c2VyOyBJIGRvbid0IHRoaW5rIHRoZXJlIGlz IGEgd2F5IHRvIGRvCj4gdGhhdCB0aGF0IGRvZXNuJ3QgaW52b2x2ZSBoYXZpbmcgbXVsdGlwbGUg c2VwYXJhdGUgZnVuY3Rpb25zIGVhY2gKPiBoYXZpbmcgc29tZSBpbmZvcm1hdGlvbiB1c2VmdWwg dG8gY29uc3RydWN0aW5nIHRoZSBtZXNzYWdlLgo+IAo+IEkga25vdyB0aGUgY29kZSBpbiBxdWVz dGlvbiBpc24ndCBpbiB0aGlzIHBhdGNoc2V0OyB0aGUgZnVuY3Rpb24KPiBtYXRjaGluZyBjb2Rl IHdhcyBpbiBvbmUgb2YgdGhlIGVhcmxpZXIgdmVyc2lvbnMgb2YgdGhlIFJGQywgYnV0IEkKPiBk cm9wcGVkIGl0IHRvIG1ha2UgdGhpcyBwYXRjaHNldCBzbWFsbGVyIGFuZCBtb3JlIG1hbmFnZWFi bGUuIFNvIEkgZ2V0Cj4gaXQgaWYgeW91IHdvdWxkIGxpa2UgbWUgdG8gZHJvcCBpdCBhbmQgYWRk IGl0IGJhY2sgaW4gd2hlbiBJIHRyeSB0bwo+IGdldCB0aGUgZnVuY3Rpb24gYW5kIHN0cnVjdHVy ZSBtYXRjaGluZyBzdHVmZiBpbiwgYnV0IEkgd291bGQgcmVhbGx5Cj4gcHJlZmVyIHRvIGtlZXAg aXQgYXMgaXMgaWYgeW91IGRvbid0IGNhcmUgdG9vIG11Y2guCgpEbyB5b3UgaGF2ZSBhIGxpbmsg dG8gdGhvc2UgZWFybGllciBwYXRjaGVzPwoKPiAKPiA+IEl0IHNlZW1zIGZhciBzaW1wbGVyIHRv IGdldCByaWQgb2YgdGhlIHN0cmluZyBzdHJlYW0gQVBJIGFuZCBqdXN0IGhhdmUgYQo+ID4gc3Ry dWN0IGZvciB0aGlzLgo+ID4KPiA+ICAgICAgICAgc3RydWN0IGt1bml0X2ZhaWxfbXNnIHsKPiA+ ICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpsaW5lOwo+ID4gICAgICAgICAgICAgICAgIGNv bnN0IGNoYXIgKmZpbGU7Cj4gPiAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZnVuYzsKPiA+ ICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICptc2c7Cj4gPiAgICAgICAgIH07Cj4gPgo+ID4g VGhlbiB5b3UgY2FuIGhhdmUgdGhlIGFzc2VydGlvbiBtYWNyb3MgY3JlYXRlIHRoaXMgb24gdGhl IHN0YWNrICh3aXRoCj4gPiBhbm90aGVyIG1hY3JvPykuCj4gPgo+ID4gICAgICAgICAjZGVmaW5l IERFRklORV9LVU5JVF9GQUlMX01TRyhuYW1lLCBfbXNnKSBcCj4gPiAgICAgICAgICAgICAgICAg c3RydWN0IGt1bml0X2ZhaWxfbXNnIG5hbWUgPSB7IFwKPiA+ICAgICAgICAgICAgICAgICAgICAg ICAgIC5saW5lID0gIF9fTElORV9fLCBcCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAuZmls ZSA9IF9fRklMRV9fLCBcCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAuZnVuYyA9IF9fZnVu Y19fLCBcCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAubXNnID0gX21zZywgXAo+ID4gICAg ICAgICAgICAgICAgIH0KPiA+Cj4gPiBJIGRvbid0IHdhbnQgdG8gZGVyYWlsIHRoaXMgd2hvbGUg c2VyaWVzIG9uIHRoaXMgdG9waWMsIGJ1dCBpdCBzZWVtcwo+ID4gbGlrZSBhIGJ1bmNoIG9mIGNv ZGUgaXMgdGhlcmUgdG8gY29uc3RydWN0IHRoaXMgc2FtZSBzZXQgb2YgaW5mb3JtYXRpb24KPiA+ IG92ZXIgYW5kIG92ZXIgYWdhaW4gaW50byBhIGJ1ZmZlciBhIGxpdHRsZSBiaXQgYXQgYSB0aW1l IGFuZCB0aGVuIHRocm93Cj4gPiBpdCBhd2F5IHdoZW4gbm90aGluZyBmYWlscyBqdXN0IGJlY2F1 c2Ugd2UgbWF5IHdhbnQgdG8gc3VwcG9ydCB0aGUgY2FzZQo+ID4gd2hlcmUgd2UgaGF2ZSBzb21l IHVuc3RydWN0dXJlZCBkYXRhIHRvIGluZm9ybSB0aGUgdXNlciBhYm91dC4KPiAKPiBZZWFoLCB0 aGF0J3MgZmFpci4gSSB0aGluayB0aGVyZSBhcmUgYSBudW1iZXIgb2YgaW1wcm92ZW1lbnRzIHRv IGJlCj4gbWFkZSB3aXRoIGhvdyB0aGUgZXhwZWN0YXRpb25zIGFyZSBkZWZpbmVkIG90aGVyIHRo YW4gdGhhdCwgYnV0IEkgd2FzCj4gaG9waW5nIEkgY291bGQgZG8gdGhhdCBhZnRlciB0aGlzIHBh dGNoc2V0IGlzIG1lcmdlZC4gSSBqdXN0IGZpZ3VyZWQKPiB3aXRoIHRoZSBraW5kcyBvZiB0aGlu Z3MgSSB3b3VsZCBsaWtlIHRvIGRvLCBpdCB3b3VsZCBsZWFkIHRvIGEgd2hvbGUKPiBuZXcgcm91 bmQgb2YgZGlzY3Vzc2lvbi4KPiAKPiBJbiBlaXRoZXIgY2FzZSwgSSB0aGluayBJIHdvdWxkIHN0 aWxsIGxpa2UgdG8gdXNlIHRoZSBgc3RydWN0Cj4ga3VuaXRfc3RyZWFtYCBhcyBwYXJ0IG9mIHRo ZSBpbnRlcmZhY2UgdG8gc2hhcmUgdGhlIGZhaWx1cmUgbWVzc2FnZQo+IHdpdGggdGhlIHRlc3Qg Y2FzZSBydW5uZXIgY29kZSBpbiB0ZXN0LmMsIGF0IGxlYXN0IGV2ZW50dWFsbHksIHNvIHRoYXQK PiBJIG9ubHkgaGF2ZSB0byBoYXZlIG9uZSB3YXkgdG8gcmVjZWl2ZSBkYXRhIGZyb20gZXhwZWN0 YXRpb25zLCBidXQgSQo+IHRoaW5rIEkgY2FuIGRvIHRoYXQgYW5kIHN0aWxsIGRvIHdoYXQgeW91 IHN1Z2dlc3QgYnkganVzdCBjb25zdHJ1Y3RpbmcKPiB0aGUga3VuaXRfc3RyZWFtIGF0IHRoZSBl bmQgb2YgZXhwZWN0YXRpb25zIHdoZXJlIGl0IGlzIGZlYXNpYmxlLgo+IAo+IEFsbCBpbiBhbGwg SSBhZ3JlZSB3aXRoIHdoYXQgeW91IGFyZSBzYXlpbmcsIGJ1dCBJIHdvdWxkIHJhdGhlciBkbyBp dAo+IGFzIGEgZm9sbG93IHVwIHBvc3NpYmx5IG9uY2Ugd2UgaGF2ZSBzb21lIG1vcmUgY29kZSBv biB0aGUgdGFibGUuIEkKPiBjb3VsZCBqdXN0IHNlZSB0aGlzIG9wZW5pbmcgdXAgYSB3aG9sZSBu ZXcgY2FuIG9mIHdvcm1zIHdoZXJlIHdlCj4gZGViYXRlIGFib3V0IGV4YWN0bHkgaG93IGV4cGVj dGF0aW9ucyBhbmQgYXNzZXJ0aW9ucyB3b3JrIGZvciBhbm90aGVyCj4gc2V2ZXJhbCBtb250aHMs IG9ubHkgdG8gcmlwIGl0IGFsbCBvdXQgc2hvcnRseSB0aGVyZSBhZnRlci4gSSBrbm93Cj4gdGhh dCdzIGhvdyB0aGVzZSB0aGluZ3MgZ28sIGJ1dCB0aGF0J3MgbXkgcHJlZmVyZW5jZS4KPiAKPiBJ IGNhbiBkbyB3aGF0IHlvdSBzdWdnZXN0IGlmIHlvdSBmZWVsIHN0cm9uZ2x5IGFib3V0IGl0LCBi dXQgSSB3b3VsZAo+IHByZWZlciB0byBob2xkIG9mZiB1bnRpbCBsYXRlci4gSXQncyB5b3VyIGNh bGwuCj4gCgpUaGUgY3J1eCBvZiBteSBjb21wbGFpbnQgaXMgdGhhdCB0aGUgc3RyaW5nIHN0cmVh bSBBUEkgaXMgdG9vIGxvb3NlbHkKZGVmaW5lZCB0byBiZSB1c2FibGUuIEl0IGFsbG93cyB0ZXN0 cyB0byBidWlsZCB1cCBhIHN0cmluZyBvZgp1bnN0cnVjdHVyZWQgaW5mb3JtYXRpb24sIGJ1dCB3 aXRoIGNlcnRhaW4gY2FsbGluZyBjb25zdHJhaW50cyBzbyB3ZQpoYXZlIHRvIHRyZWFkIGNhcmVm dWxseS4gSWYgdGhlcmUgd2FzIG1vcmUgc3RydWN0dXJlIHRvIHRoZSBkYXRhIHRoYXQncwpiZWlu ZyByZWNvcmRlZCB0aGVuIHRoZSB0ZXN0IGNhc2UgcnVubmVyIGNvdWxkIG9wZXJhdGUgb24gdGhl IGRhdGEKd2l0aG91dCBoYXZpbmcgdG8gZG8gc3RyaW5nL3N0cmVhbSBvcGVyYXRpb25zLCBhbGxv Y2F0aW9ucywgZXRjLiBUaGlzCndvdWxkIG1ha2UgdGhlIGFzc2VydGlvbiBsb2dpYyBtdWNoIG1v cmUgY29uY3JldGUgYW5kIHNwZWNpZmljIHRvIGt1bml0LAppbnN0ZWFkIG9mIHRoaXMgc21hbGwg a3VuaXQgd3JhcHBlciB0aGF0J3MgYmVlbiBwbGFjZWQgb24gdG9wIG9mIHN0cmluZwpzdHJlYW0u CgpUTDtEUjogSWYgd2UgY2FuIGdldCByaWQgb2YgdGhlIHN0cmluZyBzdHJlYW0gQVBJIEknZCB2 aWV3IHRoYXQgYXMgYW4KaW1wcm92ZW1lbnQgYmVjYXVzZSBidWlsZGluZyBhcmJpdHJhcnkgc3Ry aW5ncyBpbiB0aGUga2VybmVsIGlzIGNvbXBsZXgsCmVycm9yIHByb25lIGFuZCBoYXMgY2FsbGlu ZyBjb250ZXh0IGNvbmNlcm5zLgoKSXMgdGhlIGludGVudGlvbiB0aGF0IG90aGVyIGNvZGUgYmVz aWRlcyB1bml0IHRlc3RzIHdpbGwgdXNlIHRoaXMgc3RyaW5nCnN0cmVhbSBBUEkgdG8gYnVpbGQg dXAgc3RyaW5ncz8gQW55IHRhcmdldHMgaW4gbWluZD8gVGhpcyB3b3VsZCBiZSBhCmdvb2Qgd2F5 IHRvIGdldCB0aGUgQVBJIG1lcmdlZCB1cHN0cmVhbSBnaXZlbiB0aGF0IGl0cyAyMDE5IGFuZCB3 ZQpoYXZlbid0IGhhZCBzdWNoIGFuIEFQSSBpbiB0aGUga2VybmVsIHNvIGZhci4KCkFuICJvYmpl Y3Qgb3JpZW50ZWQiIChzdHJvbmcgcXVvdGVzISkgYXBwcm9hY2ggd2hlcmUga3VuaXRfZmFpbF9t c2cgaXMKdGhlIGlubmVybW9zdCBzdHJ1Y3QgaW4gc29tZSBhc3NlcnRpb24gc3BlY2lmaWMgc3Ry dWN0dXJlIG1pZ2h0IHdvcmsKbmljZWx5IGFuZCBhbGxvdyB0aGUgdGVzdCBydW5uZXIgdG8gY2Fs bCBhIGdlbmVyaWMgJ2Zvcm1hdCcgZnVuY3Rpb24gdG8KcHJpbnQgb3V0IHRoZSBtZXNzYWdlIGJh c2VkIG9uIHRoZSB0eXBlIG9mIGFzc2VydGlvbi9leHBlY3RhdGlvbiBpdCBpcy4KSXQgcHJvYmFi bHkgd291bGQgbWVhbiBsZXNzIGNvZGUgc2l6ZSB0b28gYmVjYXVzZSB0aGUgc3RyaW5ncyB0aGF0 IGFyZQpjb21tb24gd2lsbCBiZSBpbiB0aGUgY29tbW9uIHByaW50aW5nIGZ1bmN0aW9uIGluc3Rl YWQgb2YgY3JlYXRlZCB0d2ljZSwKaW4gdGhlIG1hY3Jvcy9jb2RlIGFuZCB0aGVuIGNvcGllZCB0 byB0aGUgaGVhcCBmb3IgdGhlIHN0cmluZyBzdHJlYW0uCgoJc3RydWN0IGt1bml0X2Fzc2VydCB7 CgkJY29uc3QgY2hhciAqbGluZTsKCQljb25zdCBjaGFyICpmaWxlOwoJCWNvbnN0IGNoYXIgKmZ1 bmM7CgkJdm9pZCAoKmZvcm1hdCkoc3RydWN0IGt1bml0X2Fzc2VydCAqYXNzZXJ0KTsKCX07CgoJ c3RydWN0IGt1bml0X2NvbXBhcmlzb25fYXNzZXJ0IHsKCQllbnVtIG9wZXJhdG9yIG9wZXJhdG9y OwoJCWNvbnN0IGNoYXIgKmxlZnQ7CgkJY29uc3QgY2hhciAqcmlnaHQ7CgkJc3RydWN0IGt1bml0 X2Fzc2VydCBhc3NlcnQ7Cgl9OwoKCXN0cnVjdCBrdW5pdF9ib29sX2Fzc2VydCB7CgkJY29uc3Qg Y2hhciAqdHJ1dGg7CgkJY29uc3QgY2hhciAqc3RhdGVtZW50OwoJCXN0cnVjdCBrdW5pdF9hc3Nl cnQgYXNzZXJ0OwoJfTsKCgl2b2lkIGt1bml0X2Zvcm1hdF9jb21wYXJpc29uKHN0cnVjdCBrdW5p dF9hc3NlcnQgKmFzc2VydCkKCXsKCQlzdHJ1Y3Qga3VuaXRfY29tcGFyaXNvbl9hc3NlcnQgKmNv bXAgPSBjb250YWluZXJfb2YoYXNzZXJ0LCAuLi4pCgoJCWt1bml0X3ByaW50ayguLi4pCgl9CgpN YXliZSBvdGhlciBwZW9wbGUgaGF2ZSBvcGluaW9ucyBoZXJlIG9uIGlmIHlvdSBzaG91bGQgZG8g aXQgbm93IG9yCmxhdGVyLiBGdXR1cmUgY29kaW5nIGlzIG5vdCBhIGdyZWF0IGFyZ3VtZW50IGJl Y2F1c2UgaXQncyBoYXJkIHRvCnByZWRpY3QgdGhlIGZ1dHVyZS4gT24gdGhlIG90aGVyIGhhbmQs IHRoaXMgcGF0Y2hzZXQgaXMgaW4gZ29vZCBzaGFwZSB0bwptZXJnZSBhbmQgSSdkIGxpa2UgdG8g dXNlIGl0IHRvIHdyaXRlIHVuaXQgdGVzdHMgZm9yIGNvZGUgSSBtYWludGFpbiBzbwpJIGRvbid0 IHdhbnQgdG8gc2VlIHRoaXMgc3RhbGwgb3V0LiBTb3JyeSBpZiBJJ20gb3BlbmluZyB0aGUgY2Fu IG9mCndvcm1zIHlvdSdyZSB0YWxraW5nIGFib3V0LgoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxA bGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxt YW4vbGlzdGluZm8vZHJpLWRldmVs