From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FDC936A027; Wed, 4 Feb 2026 08:11:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770192672; cv=none; b=rl4E/+zUXhQHwa6PSyjqbcf2fec5qwyvZABWCdt+Y72hysCNsQ3xYdi/nrHbgwmm8euXT+bFiy6q0YvqFAKq2g3P5Ol6HWC9S1C3EnVIKBqjAJftYd6B82MnbU9P8NaiTqObDNKNqdUttgcpuQrch3C50Qc7KEuS9xL4ES5PBxE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770192672; c=relaxed/simple; bh=8j8R8MPrfWY6vBRRIpvDiircDbGhdSwDxXfuiVs5GeI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=njr3Td8ocY2hdwhpuEjoCl2LtemEFzWZUSWnT4ypP8igm5JuQHnWcYoPyrVJwoNt8t6dpVfd3FuTVLJ2UBFf+OCeD4OVX5knf3Ru2d35mS+g/2AQrfIRgnRIYH9qC+8aK/pYldPSirN+DeMv7bB1bPTkjNiJRDrMLRWiAxYnvN4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=DsEFJ3Nh; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="DsEFJ3Nh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770192670; bh=8j8R8MPrfWY6vBRRIpvDiircDbGhdSwDxXfuiVs5GeI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DsEFJ3Nhca0gHPn0WW46xPuzuZwRmLNuOpKTYci/Grpz+8iFbAUufcYWOTdolbhe4 4Rju+q4X4pcKmAjKivkByu4y4dJjqVFYuCz5WFEYfcwMkREFh1aD8b/HUnDvbBGA4O K1Tom/wQJod9y9Z6en141msQx34QphBNYgjipqSBG0XBBmR/FBZVfKVSfxPegpTbfj w4RljDBo2vI4n3721FrPdjwSS+bIn9ahzDlJQUGlfuXZledsqf1PdT+3XYuZqoD+lC i/NCr5O3feDTRIiu+CdMizfBKEWtDKIfpGXKb9i0DyOQihsMQ5R5bLUkGRJ15nhaFH ZJJ99EmmtpDZA== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id AE37317E114C; Wed, 4 Feb 2026 09:11:09 +0100 (CET) Date: Wed, 4 Feb 2026 09:11:04 +0100 From: Boris Brezillon To: "Gary Guo" Cc: "Daniel Almeida" , "Alice Ryhl" , "Maxime Ripard" , "Rafael J. Wysocki" , "Viresh Kumar" , "Danilo Krummrich" , "Maarten Lankhorst" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" , "Drew Fustini" , "Guo Ren" , "Fu Wei" , Uwe =?UTF-8?B?S2xlaW5l?= =?UTF-8?B?LUvDtm5pZw==?= , "Michael Turquette" , "Stephen Boyd" , "Miguel Ojeda" , "Boqun Feng" , =?UTF-8?B?QmrDtnJu?= Roy Baron , "Benno Lossin" , "Andreas Hindborg" , "Trevor Gross" , , , , , , , Subject: Re: [PATCH v3 1/3] rust: clk: use the type-state pattern Message-ID: <20260204091104.0a9c4a13@fedora> In-Reply-To: References: <20260107-clk-type-state-v3-0-77d3e3ee59c2@collabora.com> <20260107-clk-type-state-v3-1-77d3e3ee59c2@collabora.com> <20260108-delectable-fennec-of-sunshine-ffca19@houat> <98CD0BF6-3350-40B9-B8A9-F569AE3E3220@collabora.com> <20260119-thundering-tested-robin-4be817@houat> <20260203113902.501e5803@fedora> <20260203150855.77c93e22@fedora> <4DD13AE1-C85F-450F-93F2-C7C75766E518@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-clk@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Gary, Daniel, On Tue, 03 Feb 2026 20:36:30 +0000 "Gary Guo" wrote: > On Tue Feb 3, 2026 at 7:26 PM GMT, Daniel Almeida wrote: > > =20 > >>=20 > >> I think it's fine to have all of these: > >> * `Clone` impl > >> * `enable` which consumes `Clk` by value and spit out `Clk` > >> * `with_enabled` that gives `&Clk` > >>=20 > >> This way, if you only want to enable in short time, you can do `with_e= nabled`. > >> If the closure callback wants to keep clock enabled for longer, it can= just do > >> `.clone()` inside the closure and obtain an owned `Clk`. > >>=20 > >> If the user just have a reference and want to enable the callback they= can do > >> `prepared_clk.clone().enable()` which gives an owned `Clk`. T= houghts? > >>=20 > >> Best, > >> Gary =20 > > > > > > I=E2=80=99m ok with what you proposed above. The only problem is that i= mplementing > > clone() is done through an Arc<*mut bindings::clk> in Boris=E2=80=99 c= urrent > > design, so this requires an extra allocation. =20 >=20 > Hmm, that's a very good point. `struct clk` is already a reference into > clk_core, so having to put another level of indirection over is not ideal. > However, if we're going to keep C code unchanged and do a zero-cost abstr= action > on the Rust side, then we won't be able to have have multiple prepare/ena= ble to > the same `struct clk` with the current design. >=20 > It feels like we can to do a trade-off and choose from: > 1. Not be able to have multiple prepare/enable calls on the same `clk` (t= his can > limit users that need dynamically enable/disable clocks, with the very= limited > exception that closure-callback is fine). > 2. Do an extra allocation > 3. Put lifetime on types that represent a prepared/enabled `Clk` > 4. Change C to make `struct clk` refcounted. It probably comes to no surprise that I'd be more in favor of option 2 or 4. Maybe option 2 first, so we can get the user-facing API merged without too much churn, and then we can see if the clk maintainers are happy adding a refcnt to struct clk to optimize things. If we really feel that the indirection/memory overhead is going to hurt us, we can also start with option 1, and extend it to 2 and/or 4 (needed to add a Clone support) when it becomes evident we can't do without it. But as I was saying in my previous reply to Daniel, I expect the extra indirection/memory overhead to be negligible since: 1. clks are usually not {prepared,enabled}/{disabled,unprepared} in a hot path 2. in the rare occasions where they might be ({dev,cpu}freq ?), this clk state change is usually one operation in an ocean of other slower operations (regulator reconfiguration, for instance, which usually goes over a slow I2C bus, or a relatively-faster-but-still-slow SPI one, at least when we compare it to an IoMem access for in-SoCs clks). So overall, the clk state change might account for a very small portion of the CPU cycles spent in this bigger operation 3. if I focus solely on the clk aspect, and look at the existing indirections in the clk framework (clk -> clk_core -> clk_{hw,ops} -> clk_methods), I'd expect the Arc indirection to be just noise in this pre-existing overhead 4. in term of memory, we're talking about 16 more bytes allocated per Clk on a 64-bit architecture (refcount is an int, but the alignment for the clk pointer forces 4 bytes of padding on most architectures). On a 64 bit arch, struct clk is 72 bytes if my math is correct, so that's a 22% overhead, compared to 11% overhead if the refcount was in struct clk (or in a struct refcounted_clk variant if we don't want C users to pay the price). Not great, but not terrible either So yeah my gut feeling is that we might be overthinking this extra allocation/indirection issue. This being said, one thing I'd really like to avoid is us being dragged into infinite discussions about a perfect implementation causing the merging of these changes to be delayed and other contributions being blocked on this (perfect is the enemy of good). I mean, option #1 is already an improvement compared to the raw functions we have at the moment, so if that's the middle-ground we agree on, I'm happy to give it my R-b. Regards, Boris From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5291BE83EED for ; Wed, 4 Feb 2026 08:11:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=uBcR36uuKGtwsWRFs9nsx+r1HWiCC9XJqn1DkYDZ3Ag=; b=PDkAsbKlZ34EEY SNpUcnb0+0v6uleXOeK0Xk6grxbJt8Mtci9tgtaSQsND7yIqgqho/zLE9b4KpxG8+e2d9jFZ+Pm1e +OVskqMTkCe8jAnkmjdHUpV+SDw+6CRZMSdNVTEoIqpXFR6tJnpH5bISFViOkKqnqis67SRCcpnsv 0u8ULphcDDmhP6//Jk7DtueWKu/jkWxBnbXlONnh5+cEQJHGlZq16XHU+F3862tef2jgm0loUTnDI HEMX12xvaeCvqdtTKe3MCXIfdXaKVbr/c6ElGM6zMAxPth0WSgI8QXB0uGTaZAdpNIfk3NiqyGhsF C/cJEoP1DCABl+Ja3ZKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vnXym-000000085Wj-3JF1; Wed, 04 Feb 2026 08:11:16 +0000 Received: from bali.collaboradmins.com ([148.251.105.195]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vnXyk-000000085WD-2rXM for linux-riscv@lists.infradead.org; Wed, 04 Feb 2026 08:11:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770192670; bh=8j8R8MPrfWY6vBRRIpvDiircDbGhdSwDxXfuiVs5GeI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DsEFJ3Nhca0gHPn0WW46xPuzuZwRmLNuOpKTYci/Grpz+8iFbAUufcYWOTdolbhe4 4Rju+q4X4pcKmAjKivkByu4y4dJjqVFYuCz5WFEYfcwMkREFh1aD8b/HUnDvbBGA4O K1Tom/wQJod9y9Z6en141msQx34QphBNYgjipqSBG0XBBmR/FBZVfKVSfxPegpTbfj w4RljDBo2vI4n3721FrPdjwSS+bIn9ahzDlJQUGlfuXZledsqf1PdT+3XYuZqoD+lC i/NCr5O3feDTRIiu+CdMizfBKEWtDKIfpGXKb9i0DyOQihsMQ5R5bLUkGRJ15nhaFH ZJJ99EmmtpDZA== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id AE37317E114C; Wed, 4 Feb 2026 09:11:09 +0100 (CET) Date: Wed, 4 Feb 2026 09:11:04 +0100 From: Boris Brezillon To: "Gary Guo" Cc: "Daniel Almeida" , "Alice Ryhl" , "Maxime Ripard" , "Rafael J. Wysocki" , "Viresh Kumar" , "Danilo Krummrich" , "Maarten Lankhorst" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" , "Drew Fustini" , "Guo Ren" , "Fu Wei" , Uwe =?UTF-8?B?S2xlaW5l?= =?UTF-8?B?LUvDtm5pZw==?= , "Michael Turquette" , "Stephen Boyd" , "Miguel Ojeda" , "Boqun Feng" , =?UTF-8?B?QmrDtnJu?= Roy Baron , "Benno Lossin" , "Andreas Hindborg" , "Trevor Gross" , , , , , , , Subject: Re: [PATCH v3 1/3] rust: clk: use the type-state pattern Message-ID: <20260204091104.0a9c4a13@fedora> In-Reply-To: References: <20260107-clk-type-state-v3-0-77d3e3ee59c2@collabora.com> <20260107-clk-type-state-v3-1-77d3e3ee59c2@collabora.com> <20260108-delectable-fennec-of-sunshine-ffca19@houat> <98CD0BF6-3350-40B9-B8A9-F569AE3E3220@collabora.com> <20260119-thundering-tested-robin-4be817@houat> <20260203113902.501e5803@fedora> <20260203150855.77c93e22@fedora> <4DD13AE1-C85F-450F-93F2-C7C75766E518@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260204_001114_885021_2C9E6A0F X-CRM114-Status: GOOD ( 29.42 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org SGkgR2FyeSwgRGFuaWVsLAoKT24gVHVlLCAwMyBGZWIgMjAyNiAyMDozNjozMCArMDAwMAoiR2Fy eSBHdW8iIDxnYXJ5QGdhcnlndW8ubmV0PiB3cm90ZToKCj4gT24gVHVlIEZlYiAzLCAyMDI2IGF0 IDc6MjYgUE0gR01ULCBEYW5pZWwgQWxtZWlkYSB3cm90ZToKPiA+ICAKPiA+PiAKPiA+PiBJIHRo aW5rIGl0J3MgZmluZSB0byBoYXZlIGFsbCBvZiB0aGVzZToKPiA+PiAqIGBDbG9uZWAgaW1wbAo+ ID4+ICogYGVuYWJsZWAgd2hpY2ggY29uc3VtZXMgYENsazxQcmVwYXJlZD5gIGJ5IHZhbHVlIGFu ZCBzcGl0IG91dCBgQ2xrPEVuYWJsZWQ+YAo+ID4+ICogYHdpdGhfZW5hYmxlZGAgdGhhdCBnaXZl cyBgJkNsazxFbmFibGVkPmAKPiA+PiAKPiA+PiBUaGlzIHdheSwgaWYgeW91IG9ubHkgd2FudCB0 byBlbmFibGUgaW4gc2hvcnQgdGltZSwgeW91IGNhbiBkbyBgd2l0aF9lbmFibGVkYC4KPiA+PiBJ ZiB0aGUgY2xvc3VyZSBjYWxsYmFjayB3YW50cyB0byBrZWVwIGNsb2NrIGVuYWJsZWQgZm9yIGxv bmdlciwgaXQgY2FuIGp1c3QgZG8KPiA+PiBgLmNsb25lKClgIGluc2lkZSB0aGUgY2xvc3VyZSBh bmQgb2J0YWluIGFuIG93bmVkIGBDbGs8RW5hYmxlZD5gLgo+ID4+IAo+ID4+IElmIHRoZSB1c2Vy IGp1c3QgaGF2ZSBhIHJlZmVyZW5jZSBhbmQgd2FudCB0byBlbmFibGUgdGhlIGNhbGxiYWNrIHRo ZXkgY2FuIGRvCj4gPj4gYHByZXBhcmVkX2Nsay5jbG9uZSgpLmVuYWJsZSgpYCB3aGljaCBnaXZl cyBhbiBvd25lZCBgQ2xrPEVuYWJsZWQ+YC4gVGhvdWdodHM/Cj4gPj4gCj4gPj4gQmVzdCwKPiA+ PiBHYXJ5ICAKPiA+Cj4gPgo+ID4gSeKAmW0gb2sgd2l0aCB3aGF0IHlvdSBwcm9wb3NlZCBhYm92 ZS4gVGhlIG9ubHkgcHJvYmxlbSBpcyB0aGF0IGltcGxlbWVudGluZwo+ID4gY2xvbmUoKSBpcyBk b25lIHRocm91Z2ggYW4gQXJjPCptdXQgYmluZGluZ3M6OmNsaz4gIGluIEJvcmlz4oCZIGN1cnJl bnQKPiA+IGRlc2lnbiwgc28gdGhpcyByZXF1aXJlcyBhbiBleHRyYSBhbGxvY2F0aW9uLiAgCj4g Cj4gSG1tLCB0aGF0J3MgYSB2ZXJ5IGdvb2QgcG9pbnQuIGBzdHJ1Y3QgY2xrYCBpcyBhbHJlYWR5 IGEgcmVmZXJlbmNlIGludG8KPiBjbGtfY29yZSwgc28gaGF2aW5nIHRvIHB1dCBhbm90aGVyIGxl dmVsIG9mIGluZGlyZWN0aW9uIG92ZXIgaXMgbm90IGlkZWFsLgo+IEhvd2V2ZXIsIGlmIHdlJ3Jl IGdvaW5nIHRvIGtlZXAgQyBjb2RlIHVuY2hhbmdlZCBhbmQgZG8gYSB6ZXJvLWNvc3QgYWJzdHJh Y3Rpb24KPiBvbiB0aGUgUnVzdCBzaWRlLCB0aGVuIHdlIHdvbid0IGJlIGFibGUgdG8gaGF2ZSBo YXZlIG11bHRpcGxlIHByZXBhcmUvZW5hYmxlIHRvCj4gdGhlIHNhbWUgYHN0cnVjdCBjbGtgIHdp dGggdGhlIGN1cnJlbnQgZGVzaWduLgo+IAo+IEl0IGZlZWxzIGxpa2Ugd2UgY2FuIHRvIGRvIGEg dHJhZGUtb2ZmIGFuZCBjaG9vc2UgZnJvbToKPiAxLiBOb3QgYmUgYWJsZSB0byBoYXZlIG11bHRp cGxlIHByZXBhcmUvZW5hYmxlIGNhbGxzIG9uIHRoZSBzYW1lIGBjbGtgICh0aGlzIGNhbgo+ICAg IGxpbWl0IHVzZXJzIHRoYXQgbmVlZCBkeW5hbWljYWxseSBlbmFibGUvZGlzYWJsZSBjbG9ja3Ms IHdpdGggdGhlIHZlcnkgbGltaXRlZAo+ICAgIGV4Y2VwdGlvbiB0aGF0IGNsb3N1cmUtY2FsbGJh Y2sgaXMgZmluZSkuCj4gMi4gRG8gYW4gZXh0cmEgYWxsb2NhdGlvbgo+IDMuIFB1dCBsaWZldGlt ZSBvbiB0eXBlcyB0aGF0IHJlcHJlc2VudCBhIHByZXBhcmVkL2VuYWJsZWQgYENsa2AKPiA0LiBD aGFuZ2UgQyB0byBtYWtlIGBzdHJ1Y3QgY2xrYCByZWZjb3VudGVkLgoKSXQgcHJvYmFibHkgY29t ZXMgdG8gbm8gc3VycHJpc2UgdGhhdCBJJ2QgYmUgbW9yZSBpbiBmYXZvciBvZiBvcHRpb24gMgpv ciA0LiBNYXliZSBvcHRpb24gMiBmaXJzdCwgc28gd2UgY2FuIGdldCB0aGUgdXNlci1mYWNpbmcg QVBJIG1lcmdlZAp3aXRob3V0IHRvbyBtdWNoIGNodXJuLCBhbmQgdGhlbiB3ZSBjYW4gc2VlIGlm IHRoZSBjbGsgbWFpbnRhaW5lcnMgYXJlCmhhcHB5IGFkZGluZyBhIHJlZmNudCB0byBzdHJ1Y3Qg Y2xrIHRvIG9wdGltaXplIHRoaW5ncy4KCklmIHdlIHJlYWxseSBmZWVsIHRoYXQgdGhlIGluZGly ZWN0aW9uL21lbW9yeSBvdmVyaGVhZCBpcyBnb2luZyB0bwpodXJ0IHVzLCB3ZSBjYW4gYWxzbyBz dGFydCB3aXRoIG9wdGlvbiAxLCBhbmQgZXh0ZW5kIGl0IHRvIDIgYW5kL29yIDQKKG5lZWRlZCB0 byBhZGQgYSBDbG9uZSBzdXBwb3J0KSB3aGVuIGl0IGJlY29tZXMgZXZpZGVudCB3ZSBjYW4ndCBk bwp3aXRob3V0IGl0LiBCdXQgYXMgSSB3YXMgc2F5aW5nIGluIG15IHByZXZpb3VzIHJlcGx5IHRv IERhbmllbCwgSQpleHBlY3QgdGhlIGV4dHJhIGluZGlyZWN0aW9uL21lbW9yeSBvdmVyaGVhZCB0 byBiZSBuZWdsaWdpYmxlIHNpbmNlOgoKMS4gY2xrcyBhcmUgdXN1YWxseSBub3Qge3ByZXBhcmVk LGVuYWJsZWR9L3tkaXNhYmxlZCx1bnByZXBhcmVkfSBpbiBhCiAgIGhvdCBwYXRoCjIuIGluIHRo ZSByYXJlIG9jY2FzaW9ucyB3aGVyZSB0aGV5IG1pZ2h0IGJlICh7ZGV2LGNwdX1mcmVxID8pLCB0 aGlzCiAgIGNsayBzdGF0ZSBjaGFuZ2UgaXMgdXN1YWxseSBvbmUgb3BlcmF0aW9uIGluIGFuIG9j ZWFuIG9mIG90aGVyCiAgIHNsb3dlciBvcGVyYXRpb25zIChyZWd1bGF0b3IgcmVjb25maWd1cmF0 aW9uLCBmb3IgaW5zdGFuY2UsIHdoaWNoCiAgIHVzdWFsbHkgZ29lcyBvdmVyIGEgc2xvdyBJMkMg YnVzLCBvciBhCiAgIHJlbGF0aXZlbHktZmFzdGVyLWJ1dC1zdGlsbC1zbG93IFNQSSBvbmUsIGF0 IGxlYXN0IHdoZW4gd2UgY29tcGFyZQogICBpdCB0byBhbiBJb01lbSBhY2Nlc3MgZm9yIGluLVNv Q3MgY2xrcykuIFNvIG92ZXJhbGwsIHRoZSBjbGsgc3RhdGUKICAgY2hhbmdlIG1pZ2h0IGFjY291 bnQgZm9yIGEgdmVyeSBzbWFsbCBwb3J0aW9uIG9mIHRoZSBDUFUgY3ljbGVzCiAgIHNwZW50IGlu IHRoaXMgYmlnZ2VyIG9wZXJhdGlvbgozLiBpZiBJIGZvY3VzIHNvbGVseSBvbiB0aGUgY2xrIGFz cGVjdCwgYW5kIGxvb2sgYXQgdGhlIGV4aXN0aW5nCiAgIGluZGlyZWN0aW9ucyBpbiB0aGUgY2xr IGZyYW1ld29yayAoY2xrIC0+IGNsa19jb3JlIC0+IGNsa197aHcsb3BzfSAtPgogICBjbGtfbWV0 aG9kcyksIEknZCBleHBlY3QgdGhlIEFyYyBpbmRpcmVjdGlvbiB0byBiZSBqdXN0IG5vaXNlIGlu CiAgIHRoaXMgcHJlLWV4aXN0aW5nIG92ZXJoZWFkCjQuIGluIHRlcm0gb2YgbWVtb3J5LCB3ZSdy ZSB0YWxraW5nIGFib3V0IDE2IG1vcmUgYnl0ZXMgYWxsb2NhdGVkIHBlcgogICBDbGsgb24gYSA2 NC1iaXQgYXJjaGl0ZWN0dXJlIChyZWZjb3VudCBpcyBhbiBpbnQsIGJ1dCB0aGUgYWxpZ25tZW50 CiAgIGZvciB0aGUgY2xrIHBvaW50ZXIgZm9yY2VzIDQgYnl0ZXMgb2YgcGFkZGluZyBvbiBtb3N0 CiAgIGFyY2hpdGVjdHVyZXMpLiBPbiBhIDY0IGJpdCBhcmNoLCBzdHJ1Y3QgY2xrIGlzIDcyIGJ5 dGVzIGlmIG15IG1hdGgKICAgaXMgY29ycmVjdCwgc28gdGhhdCdzIGEgMjIlIG92ZXJoZWFkLCBj b21wYXJlZCB0byAxMSUgb3ZlcmhlYWQgaWYKICAgdGhlIHJlZmNvdW50IHdhcyBpbiBzdHJ1Y3Qg Y2xrIChvciBpbiBhIHN0cnVjdAogICByZWZjb3VudGVkX2NsayB2YXJpYW50IGlmIHdlIGRvbid0 IHdhbnQgQyB1c2VycyB0byBwYXkgdGhlIHByaWNlKS4KICAgTm90IGdyZWF0LCBidXQgbm90IHRl cnJpYmxlIGVpdGhlcgoKU28geWVhaCBteSBndXQgZmVlbGluZyBpcyB0aGF0IHdlIG1pZ2h0IGJl IG92ZXJ0aGlua2luZyB0aGlzIGV4dHJhCmFsbG9jYXRpb24vaW5kaXJlY3Rpb24gaXNzdWUuIFRo aXMgYmVpbmcgc2FpZCwgb25lIHRoaW5nIEknZCByZWFsbHkgbGlrZQp0byBhdm9pZCBpcyB1cyBi ZWluZyBkcmFnZ2VkIGludG8gaW5maW5pdGUgZGlzY3Vzc2lvbnMgYWJvdXQgYSBwZXJmZWN0Cmlt cGxlbWVudGF0aW9uIGNhdXNpbmcgdGhlIG1lcmdpbmcgb2YgdGhlc2UgY2hhbmdlcyB0byBiZSBk ZWxheWVkIGFuZApvdGhlciBjb250cmlidXRpb25zIGJlaW5nIGJsb2NrZWQgb24gdGhpcyAocGVy ZmVjdCBpcyB0aGUgZW5lbXkgb2YKZ29vZCkuIEkgbWVhbiwgb3B0aW9uICMxIGlzIGFscmVhZHkg YW4gaW1wcm92ZW1lbnQgY29tcGFyZWQgdG8gdGhlIHJhdwpmdW5jdGlvbnMgd2UgaGF2ZSBhdCB0 aGUgbW9tZW50LCBzbyBpZiB0aGF0J3MgdGhlIG1pZGRsZS1ncm91bmQgd2UKYWdyZWUgb24sIEkn bSBoYXBweSB0byBnaXZlIGl0IG15IFItYi4KClJlZ2FyZHMsCgpCb3JpcwoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtcmlzY3YgbWFpbGluZyBs aXN0CmxpbnV4LXJpc2N2QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVh ZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1yaXNjdgo=