From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752734AbbBKLXz (ORCPT ); Wed, 11 Feb 2015 06:23:55 -0500 Received: from mail-ie0-f180.google.com ([209.85.223.180]:44406 "EHLO mail-ie0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752064AbbBKLXx (ORCPT ); Wed, 11 Feb 2015 06:23:53 -0500 MIME-Version: 1.0 In-Reply-To: <20150211111258.GP8656@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <54DB12B5.4080000@samsung.com> <20150211111258.GP8656@n2100.arm.linux.org.uk> Date: Wed, 11 Feb 2015 06:23:52 -0500 Message-ID: Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms From: Rob Clark To: Russell King - ARM Linux Cc: Marek Szyprowski , Sumit Semwal , Linux Kernel Mailing List , "linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , "linux-arm-kernel@lists.infradead.org" , linux-mm , Robin Murphy , Linaro Kernel Mailman List , Tomasz Stanislawski , Daniel Vetter Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux wrote: > On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote: >> Hello, >> >> On 2015-01-27 09:25, Sumit Semwal wrote: >> >Add some helpers to share the constraints of devices while attaching >> >to the dmabuf buffer. >> > >> >At each attach, the constraints are calculated based on the following: >> >- max_segment_size, max_segment_count, segment_boundary_mask from >> > device_dma_parameters. >> > >> >In case the attaching device's constraints don't match up, attach() fails. >> > >> >At detach, the constraints are recalculated based on the remaining >> >attached devices. >> > >> >Two helpers are added: >> >- dma_buf_get_constraints - which gives the current constraints as calculated >> > during each attach on the buffer till the time, >> >- dma_buf_recalc_constraints - which recalculates the constraints for all >> > currently attached devices for the 'paranoid' ones amongst us. >> > >> >The idea of this patch is largely taken from Rob Clark's RFC at >> >https://lkml.org/lkml/2012/7/19/285, and the comments received on it. >> > >> >Cc: Rob Clark >> >Signed-off-by: Sumit Semwal >> >> The code looks okay, although it will probably will work well only with >> typical cases like 'contiguous memory needed' or 'no constraints at all' >> (iommu). > > Which is a damn good reason to NAK it - by that admission, it's a half-baked > idea. > > If all we want to know is whether the importer can accept only contiguous > memory or not, make a flag to do that, and allow the exporter to test this > flag. Don't over-engineer this to make it _seem_ like it can do something > that it actually totally fails with. jfyi, I agree with that.. I think the flag is probably the right approach to start with. At the end of the day it *is* still just an in-kernel API (and not something that ends up as userspace ABI) so when we come up with the use case to make it more generic we can. Vs. making it look like something more generic when it isn't really yet. > As I've already pointed out, there's a major problem if you have already > had a less restrictive attachment which has an active mapping, and a new > more restrictive attachment comes along later. > > It seems from Rob's descriptions that we also need another flag in the > importer to indicate whether it wants to have a valid struct page in the > scatter list, or whether it (correctly) uses the DMA accessors on the > scatter list - so that exporters can reject importers which are buggy. to be completely generic, we would really need a way that the device could take over only just the last iommu (in case there were multiple levels of address translation).. I'm not completely sure, but I *think* the other arm gpu's have their own internal mmu for doing context switching, etc, so if there is an additional iommu in front of them they may actually still want to use the normal dma api's. Someone please contradict me if I am wrong. If this ends up being an issue only for msm, then I'm completely ok with the easier option of a less generic solution.. BR, -R > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ie0-f180.google.com ([209.85.223.180]:44406 "EHLO mail-ie0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752064AbbBKLXx (ORCPT ); Wed, 11 Feb 2015 06:23:53 -0500 MIME-Version: 1.0 In-Reply-To: <20150211111258.GP8656@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <54DB12B5.4080000@samsung.com> <20150211111258.GP8656@n2100.arm.linux.org.uk> Date: Wed, 11 Feb 2015 06:23:52 -0500 Message-ID: Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms From: Rob Clark To: Russell King - ARM Linux Cc: Marek Szyprowski , Sumit Semwal , Linux Kernel Mailing List , "linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , "linux-arm-kernel@lists.infradead.org" , linux-mm , Robin Murphy , Linaro Kernel Mailman List , Tomasz Stanislawski , Daniel Vetter Content-Type: text/plain; charset=UTF-8 Sender: linux-media-owner@vger.kernel.org List-ID: On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux wrote: > On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote: >> Hello, >> >> On 2015-01-27 09:25, Sumit Semwal wrote: >> >Add some helpers to share the constraints of devices while attaching >> >to the dmabuf buffer. >> > >> >At each attach, the constraints are calculated based on the following: >> >- max_segment_size, max_segment_count, segment_boundary_mask from >> > device_dma_parameters. >> > >> >In case the attaching device's constraints don't match up, attach() fails. >> > >> >At detach, the constraints are recalculated based on the remaining >> >attached devices. >> > >> >Two helpers are added: >> >- dma_buf_get_constraints - which gives the current constraints as calculated >> > during each attach on the buffer till the time, >> >- dma_buf_recalc_constraints - which recalculates the constraints for all >> > currently attached devices for the 'paranoid' ones amongst us. >> > >> >The idea of this patch is largely taken from Rob Clark's RFC at >> >https://lkml.org/lkml/2012/7/19/285, and the comments received on it. >> > >> >Cc: Rob Clark >> >Signed-off-by: Sumit Semwal >> >> The code looks okay, although it will probably will work well only with >> typical cases like 'contiguous memory needed' or 'no constraints at all' >> (iommu). > > Which is a damn good reason to NAK it - by that admission, it's a half-baked > idea. > > If all we want to know is whether the importer can accept only contiguous > memory or not, make a flag to do that, and allow the exporter to test this > flag. Don't over-engineer this to make it _seem_ like it can do something > that it actually totally fails with. jfyi, I agree with that.. I think the flag is probably the right approach to start with. At the end of the day it *is* still just an in-kernel API (and not something that ends up as userspace ABI) so when we come up with the use case to make it more generic we can. Vs. making it look like something more generic when it isn't really yet. > As I've already pointed out, there's a major problem if you have already > had a less restrictive attachment which has an active mapping, and a new > more restrictive attachment comes along later. > > It seems from Rob's descriptions that we also need another flag in the > importer to indicate whether it wants to have a valid struct page in the > scatter list, or whether it (correctly) uses the DMA accessors on the > scatter list - so that exporters can reject importers which are buggy. to be completely generic, we would really need a way that the device could take over only just the last iommu (in case there were multiple levels of address translation).. I'm not completely sure, but I *think* the other arm gpu's have their own internal mmu for doing context switching, etc, so if there is an additional iommu in front of them they may actually still want to use the normal dma api's. Someone please contradict me if I am wrong. If this ends up being an issue only for msm, then I'm completely ok with the easier option of a less generic solution.. BR, -R > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by kanga.kvack.org (Postfix) with ESMTP id C2AC06B0032 for ; Wed, 11 Feb 2015 06:23:53 -0500 (EST) Received: by iecrl12 with SMTP id rl12so750722iec.2 for ; Wed, 11 Feb 2015 03:23:53 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com. [209.85.223.176]) by mx.google.com with ESMTPS id eh8si11367538igb.48.2015.02.11.03.23.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 03:23:53 -0800 (PST) Received: by iecrl12 with SMTP id rl12so750677iec.2 for ; Wed, 11 Feb 2015 03:23:53 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20150211111258.GP8656@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <54DB12B5.4080000@samsung.com> <20150211111258.GP8656@n2100.arm.linux.org.uk> Date: Wed, 11 Feb 2015 06:23:52 -0500 Message-ID: Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms From: Rob Clark Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Russell King - ARM Linux Cc: Marek Szyprowski , Sumit Semwal , Linux Kernel Mailing List , "linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , "linux-arm-kernel@lists.infradead.org" , linux-mm , Robin Murphy , Linaro Kernel Mailman List , Tomasz Stanislawski , Daniel Vetter On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux wrote: > On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote: >> Hello, >> >> On 2015-01-27 09:25, Sumit Semwal wrote: >> >Add some helpers to share the constraints of devices while attaching >> >to the dmabuf buffer. >> > >> >At each attach, the constraints are calculated based on the following: >> >- max_segment_size, max_segment_count, segment_boundary_mask from >> > device_dma_parameters. >> > >> >In case the attaching device's constraints don't match up, attach() fails. >> > >> >At detach, the constraints are recalculated based on the remaining >> >attached devices. >> > >> >Two helpers are added: >> >- dma_buf_get_constraints - which gives the current constraints as calculated >> > during each attach on the buffer till the time, >> >- dma_buf_recalc_constraints - which recalculates the constraints for all >> > currently attached devices for the 'paranoid' ones amongst us. >> > >> >The idea of this patch is largely taken from Rob Clark's RFC at >> >https://lkml.org/lkml/2012/7/19/285, and the comments received on it. >> > >> >Cc: Rob Clark >> >Signed-off-by: Sumit Semwal >> >> The code looks okay, although it will probably will work well only with >> typical cases like 'contiguous memory needed' or 'no constraints at all' >> (iommu). > > Which is a damn good reason to NAK it - by that admission, it's a half-baked > idea. > > If all we want to know is whether the importer can accept only contiguous > memory or not, make a flag to do that, and allow the exporter to test this > flag. Don't over-engineer this to make it _seem_ like it can do something > that it actually totally fails with. jfyi, I agree with that.. I think the flag is probably the right approach to start with. At the end of the day it *is* still just an in-kernel API (and not something that ends up as userspace ABI) so when we come up with the use case to make it more generic we can. Vs. making it look like something more generic when it isn't really yet. > As I've already pointed out, there's a major problem if you have already > had a less restrictive attachment which has an active mapping, and a new > more restrictive attachment comes along later. > > It seems from Rob's descriptions that we also need another flag in the > importer to indicate whether it wants to have a valid struct page in the > scatter list, or whether it (correctly) uses the DMA accessors on the > scatter list - so that exporters can reject importers which are buggy. to be completely generic, we would really need a way that the device could take over only just the last iommu (in case there were multiple levels of address translation).. I'm not completely sure, but I *think* the other arm gpu's have their own internal mmu for doing context switching, etc, so if there is an additional iommu in front of them they may actually still want to use the normal dma api's. Someone please contradict me if I am wrong. If this ends up being an issue only for msm, then I'm completely ok with the easier option of a less generic solution.. BR, -R > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: robdclark@gmail.com (Rob Clark) Date: Wed, 11 Feb 2015 06:23:52 -0500 Subject: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms In-Reply-To: <20150211111258.GP8656@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <54DB12B5.4080000@samsung.com> <20150211111258.GP8656@n2100.arm.linux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux wrote: > On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote: >> Hello, >> >> On 2015-01-27 09:25, Sumit Semwal wrote: >> >Add some helpers to share the constraints of devices while attaching >> >to the dmabuf buffer. >> > >> >At each attach, the constraints are calculated based on the following: >> >- max_segment_size, max_segment_count, segment_boundary_mask from >> > device_dma_parameters. >> > >> >In case the attaching device's constraints don't match up, attach() fails. >> > >> >At detach, the constraints are recalculated based on the remaining >> >attached devices. >> > >> >Two helpers are added: >> >- dma_buf_get_constraints - which gives the current constraints as calculated >> > during each attach on the buffer till the time, >> >- dma_buf_recalc_constraints - which recalculates the constraints for all >> > currently attached devices for the 'paranoid' ones amongst us. >> > >> >The idea of this patch is largely taken from Rob Clark's RFC at >> >https://lkml.org/lkml/2012/7/19/285, and the comments received on it. >> > >> >Cc: Rob Clark >> >Signed-off-by: Sumit Semwal >> >> The code looks okay, although it will probably will work well only with >> typical cases like 'contiguous memory needed' or 'no constraints at all' >> (iommu). > > Which is a damn good reason to NAK it - by that admission, it's a half-baked > idea. > > If all we want to know is whether the importer can accept only contiguous > memory or not, make a flag to do that, and allow the exporter to test this > flag. Don't over-engineer this to make it _seem_ like it can do something > that it actually totally fails with. jfyi, I agree with that.. I think the flag is probably the right approach to start with. At the end of the day it *is* still just an in-kernel API (and not something that ends up as userspace ABI) so when we come up with the use case to make it more generic we can. Vs. making it look like something more generic when it isn't really yet. > As I've already pointed out, there's a major problem if you have already > had a less restrictive attachment which has an active mapping, and a new > more restrictive attachment comes along later. > > It seems from Rob's descriptions that we also need another flag in the > importer to indicate whether it wants to have a valid struct page in the > scatter list, or whether it (correctly) uses the DMA accessors on the > scatter list - so that exporters can reject importers which are buggy. to be completely generic, we would really need a way that the device could take over only just the last iommu (in case there were multiple levels of address translation).. I'm not completely sure, but I *think* the other arm gpu's have their own internal mmu for doing context switching, etc, so if there is an additional iommu in front of them they may actually still want to use the normal dma api's. Someone please contradict me if I am wrong. If this ends up being an issue only for msm, then I'm completely ok with the easier option of a less generic solution.. BR, -R > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Date: Wed, 11 Feb 2015 06:23:52 -0500 Message-ID: References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <54DB12B5.4080000@samsung.com> <20150211111258.GP8656@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by gabe.freedesktop.org (Postfix) with ESMTP id 5E672892E7 for ; Wed, 11 Feb 2015 03:23:53 -0800 (PST) Received: by iecrd18 with SMTP id rd18so3128199iec.5 for ; Wed, 11 Feb 2015 03:23:53 -0800 (PST) In-Reply-To: <20150211111258.GP8656@n2100.arm.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Russell King - ARM Linux Cc: Linaro Kernel Mailman List , Tomasz Stanislawski , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , linux-mm , Marek Szyprowski , Robin Murphy , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" List-Id: dri-devel@lists.freedesktop.org T24gV2VkLCBGZWIgMTEsIDIwMTUgYXQgNjoxMiBBTSwgUnVzc2VsbCBLaW5nIC0gQVJNIExpbnV4 CjxsaW51eEBhcm0ubGludXgub3JnLnVrPiB3cm90ZToKPiBPbiBXZWQsIEZlYiAxMSwgMjAxNSBh dCAwOToyODozN0FNICswMTAwLCBNYXJlayBTenlwcm93c2tpIHdyb3RlOgo+PiBIZWxsbywKPj4K Pj4gT24gMjAxNS0wMS0yNyAwOToyNSwgU3VtaXQgU2Vtd2FsIHdyb3RlOgo+PiA+QWRkIHNvbWUg aGVscGVycyB0byBzaGFyZSB0aGUgY29uc3RyYWludHMgb2YgZGV2aWNlcyB3aGlsZSBhdHRhY2hp bmcKPj4gPnRvIHRoZSBkbWFidWYgYnVmZmVyLgo+PiA+Cj4+ID5BdCBlYWNoIGF0dGFjaCwgdGhl IGNvbnN0cmFpbnRzIGFyZSBjYWxjdWxhdGVkIGJhc2VkIG9uIHRoZSBmb2xsb3dpbmc6Cj4+ID4t IG1heF9zZWdtZW50X3NpemUsIG1heF9zZWdtZW50X2NvdW50LCBzZWdtZW50X2JvdW5kYXJ5X21h c2sgZnJvbQo+PiA+ICAgIGRldmljZV9kbWFfcGFyYW1ldGVycy4KPj4gPgo+PiA+SW4gY2FzZSB0 aGUgYXR0YWNoaW5nIGRldmljZSdzIGNvbnN0cmFpbnRzIGRvbid0IG1hdGNoIHVwLCBhdHRhY2go KSBmYWlscy4KPj4gPgo+PiA+QXQgZGV0YWNoLCB0aGUgY29uc3RyYWludHMgYXJlIHJlY2FsY3Vs YXRlZCBiYXNlZCBvbiB0aGUgcmVtYWluaW5nCj4+ID5hdHRhY2hlZCBkZXZpY2VzLgo+PiA+Cj4+ ID5Ud28gaGVscGVycyBhcmUgYWRkZWQ6Cj4+ID4tIGRtYV9idWZfZ2V0X2NvbnN0cmFpbnRzIC0g d2hpY2ggZ2l2ZXMgdGhlIGN1cnJlbnQgY29uc3RyYWludHMgYXMgY2FsY3VsYXRlZAo+PiA+ICAg ICAgIGR1cmluZyBlYWNoIGF0dGFjaCBvbiB0aGUgYnVmZmVyIHRpbGwgdGhlIHRpbWUsCj4+ID4t IGRtYV9idWZfcmVjYWxjX2NvbnN0cmFpbnRzIC0gd2hpY2ggcmVjYWxjdWxhdGVzIHRoZSBjb25z dHJhaW50cyBmb3IgYWxsCj4+ID4gICAgICAgY3VycmVudGx5IGF0dGFjaGVkIGRldmljZXMgZm9y IHRoZSAncGFyYW5vaWQnIG9uZXMgYW1vbmdzdCB1cy4KPj4gPgo+PiA+VGhlIGlkZWEgb2YgdGhp cyBwYXRjaCBpcyBsYXJnZWx5IHRha2VuIGZyb20gUm9iIENsYXJrJ3MgUkZDIGF0Cj4+ID5odHRw czovL2xrbWwub3JnL2xrbWwvMjAxMi83LzE5LzI4NSwgYW5kIHRoZSBjb21tZW50cyByZWNlaXZl ZCBvbiBpdC4KPj4gPgo+PiA+Q2M6IFJvYiBDbGFyayA8cm9iZGNsYXJrQGdtYWlsLmNvbT4KPj4g PlNpZ25lZC1vZmYtYnk6IFN1bWl0IFNlbXdhbCA8c3VtaXQuc2Vtd2FsQGxpbmFyby5vcmc+Cj4+ Cj4+IFRoZSBjb2RlIGxvb2tzIG9rYXksIGFsdGhvdWdoIGl0IHdpbGwgcHJvYmFibHkgd2lsbCB3 b3JrIHdlbGwgb25seSB3aXRoCj4+IHR5cGljYWwgY2FzZXMgbGlrZSAnY29udGlndW91cyBtZW1v cnkgbmVlZGVkJyBvciAnbm8gY29uc3RyYWludHMgYXQgYWxsJwo+PiAoaW9tbXUpLgo+Cj4gV2hp Y2ggaXMgYSBkYW1uIGdvb2QgcmVhc29uIHRvIE5BSyBpdCAtIGJ5IHRoYXQgYWRtaXNzaW9uLCBp dCdzIGEgaGFsZi1iYWtlZAo+IGlkZWEuCj4KPiBJZiBhbGwgd2Ugd2FudCB0byBrbm93IGlzIHdo ZXRoZXIgdGhlIGltcG9ydGVyIGNhbiBhY2NlcHQgb25seSBjb250aWd1b3VzCj4gbWVtb3J5IG9y IG5vdCwgbWFrZSBhIGZsYWcgdG8gZG8gdGhhdCwgYW5kIGFsbG93IHRoZSBleHBvcnRlciB0byB0 ZXN0IHRoaXMKPiBmbGFnLiAgRG9uJ3Qgb3Zlci1lbmdpbmVlciB0aGlzIHRvIG1ha2UgaXQgX3Nl ZW1fIGxpa2UgaXQgY2FuIGRvIHNvbWV0aGluZwo+IHRoYXQgaXQgYWN0dWFsbHkgdG90YWxseSBm YWlscyB3aXRoLgoKamZ5aSwgSSBhZ3JlZSB3aXRoIHRoYXQuLiBJIHRoaW5rIHRoZSBmbGFnIGlz IHByb2JhYmx5IHRoZSByaWdodAphcHByb2FjaCB0byBzdGFydCB3aXRoLiAgQXQgdGhlIGVuZCBv ZiB0aGUgZGF5IGl0ICppcyogc3RpbGwganVzdCBhbgppbi1rZXJuZWwgQVBJIChhbmQgbm90IHNv bWV0aGluZyB0aGF0IGVuZHMgdXAgYXMgdXNlcnNwYWNlIEFCSSkgc28Kd2hlbiB3ZSBjb21lIHVw IHdpdGggdGhlIHVzZSBjYXNlIHRvIG1ha2UgaXQgbW9yZSBnZW5lcmljIHdlIGNhbi4gIFZzLgpt YWtpbmcgaXQgbG9vayBsaWtlIHNvbWV0aGluZyBtb3JlIGdlbmVyaWMgd2hlbiBpdCBpc24ndCBy ZWFsbHkgeWV0LgoKPiBBcyBJJ3ZlIGFscmVhZHkgcG9pbnRlZCBvdXQsIHRoZXJlJ3MgYSBtYWpv ciBwcm9ibGVtIGlmIHlvdSBoYXZlIGFscmVhZHkKPiBoYWQgYSBsZXNzIHJlc3RyaWN0aXZlIGF0 dGFjaG1lbnQgd2hpY2ggaGFzIGFuIGFjdGl2ZSBtYXBwaW5nLCBhbmQgYSBuZXcKPiBtb3JlIHJl c3RyaWN0aXZlIGF0dGFjaG1lbnQgY29tZXMgYWxvbmcgbGF0ZXIuCj4KPiBJdCBzZWVtcyBmcm9t IFJvYidzIGRlc2NyaXB0aW9ucyB0aGF0IHdlIGFsc28gbmVlZCBhbm90aGVyIGZsYWcgaW4gdGhl Cj4gaW1wb3J0ZXIgdG8gaW5kaWNhdGUgd2hldGhlciBpdCB3YW50cyB0byBoYXZlIGEgdmFsaWQg c3RydWN0IHBhZ2UgaW4gdGhlCj4gc2NhdHRlciBsaXN0LCBvciB3aGV0aGVyIGl0IChjb3JyZWN0 bHkpIHVzZXMgdGhlIERNQSBhY2Nlc3NvcnMgb24gdGhlCj4gc2NhdHRlciBsaXN0IC0gc28gdGhh dCBleHBvcnRlcnMgY2FuIHJlamVjdCBpbXBvcnRlcnMgd2hpY2ggYXJlIGJ1Z2d5LgoKdG8gYmUg Y29tcGxldGVseSBnZW5lcmljLCB3ZSB3b3VsZCByZWFsbHkgbmVlZCBhIHdheSB0aGF0IHRoZSBk ZXZpY2UKY291bGQgdGFrZSBvdmVyIG9ubHkganVzdCB0aGUgbGFzdCBpb21tdSAoaW4gY2FzZSB0 aGVyZSB3ZXJlIG11bHRpcGxlCmxldmVscyBvZiBhZGRyZXNzIHRyYW5zbGF0aW9uKS4uCgpJJ20g bm90IGNvbXBsZXRlbHkgc3VyZSwgYnV0IEkgKnRoaW5rKiB0aGUgb3RoZXIgYXJtIGdwdSdzIGhh dmUgdGhlaXIKb3duIGludGVybmFsIG1tdSBmb3IgZG9pbmcgY29udGV4dCBzd2l0Y2hpbmcsIGV0 Yywgc28gaWYgdGhlcmUgaXMgYW4KYWRkaXRpb25hbCBpb21tdSBpbiBmcm9udCBvZiB0aGVtIHRo ZXkgbWF5IGFjdHVhbGx5IHN0aWxsIHdhbnQgdG8gdXNlCnRoZSBub3JtYWwgZG1hIGFwaSdzLiAg U29tZW9uZSBwbGVhc2UgY29udHJhZGljdCBtZSBpZiBJIGFtIHdyb25nLiAgSWYKdGhpcyBlbmRz IHVwIGJlaW5nIGFuIGlzc3VlIG9ubHkgZm9yIG1zbSwgdGhlbiBJJ20gY29tcGxldGVseSBvayB3 aXRoCnRoZSBlYXNpZXIgb3B0aW9uIG9mIGEgbGVzcyBnZW5lcmljIHNvbHV0aW9uLi4KCkJSLAot UgoKPgo+IC0tCj4gRlRUQyBicm9hZGJhbmQgZm9yIDAuOG1pbGUgbGluZTogY3VycmVudGx5IGF0 IDEwLjVNYnBzIGRvd24gNDAwa2JwcyB1cAo+IGFjY29yZGluZyB0byBzcGVlZHRlc3QubmV0Lgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwg bWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo=