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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17731C433ED for ; Mon, 26 Apr 2021 11:20:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CCA8C61249 for ; Mon, 26 Apr 2021 11:20:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232520AbhDZLU7 (ORCPT ); Mon, 26 Apr 2021 07:20:59 -0400 Received: from mx1.uni-regensburg.de ([194.94.157.146]:59160 "EHLO mx1.uni-regensburg.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232490AbhDZLU7 (ORCPT ); Mon, 26 Apr 2021 07:20:59 -0400 X-Greylist: delayed 311 seconds by postgrey-1.27 at vger.kernel.org; Mon, 26 Apr 2021 07:20:59 EDT Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3B33C600004D for ; Mon, 26 Apr 2021 13:15:00 +0200 (CEST) Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx1.uni-regensburg.de (Postfix) with ESMTP id 0A4D76000059 for ; Mon, 26 Apr 2021 13:15:00 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 26 Apr 2021 13:14:59 +0200 Message-Id: <6086A0B2020000A100040BBE@gwsmtp.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 18.3.1 Date: Mon, 26 Apr 2021 13:14:58 +0200 From: "Ulrich Windl" To: , Cc: , , "systemd-devel@lists.freedesktop.org" , , , , , Subject: Antw: [EXT] Re: [systemd-devel] RFC: one more time: SCSI device identification References: <06489ea37311fe7bf73b27a41b5209ee4cca85fe.camel@suse.com> <685c40341d2ddef2fe5a54dd656d10104b0c1bfa.camel@suse.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org >>> Martin Wilck schrieb am 23.04.2021 um 12:28 in Nachricht : > On Thu, 2021‑04‑22 at 21:40 ‑0400, Martin K. Petersen wrote: >> >> Martin, >> >> > I suppose 99.9% of users never bother with customizing the udev >> > rules. >> >> Except for the other 99.9%, perhaps? :) We definitely have many users >> that tweak udev storage rules for a variety of reasons. Including >> being >> able to use RII for LUN naming purposes. >> >> > But we can actually combine both approaches. If "wwid" yields a >> > good >> > value most of the time (which is true IMO), we could make user >> > space >> > rely on it by default, and make it possible to set an udev property >> > (e.g. ENV{ID_LEGACY}="1") to tell udev rules to determine WWID >> > differently. User‑space apps like multipath could check the >> > ID_LEGACY >> > property to determine whether or not reading the "wwid" attribute >> > would >> > be consistent with udev. That would simplify matters a lot for us >> > (Ben, >> > do you agree?), without the need of adding endless BLIST entries. >> >> That's fine with me. >> >> > AFAICT, no major distribution uses "wwid" for this purpose (yet). >> >> We definitely have users that currently rely on wwid, although >> probably >> not through standard distro scripts. >> >> > In a recent discussion with Hannes, the idea came up that the >> > priority >> > of "SCSI name string" designators should actually depend on their >> > subtype. "naa." name strings should map to the respective NAA >> > descriptors, and "eui.", likewise (only "iqn." descriptors have no >> > binary counterpart; we thought they should rather be put below NAA, >> > prio‑wise). >> >> I like what NVMe did wrt. to exporting eui, nguid, uuid separately >> from >> the best‑effort wwid. That's why I suggested separate sysfs files for >> the various page 0x83 descriptors. I like the idea of being able to >> explicitly ask for an eui if that's what I need. But that appears to >> be >> somewhat orthogonal to your request. >> >> > I wonder if you'd agree with a change made that way for "wwid". I >> > suppose you don't. I'd then propose to add a new attribute >> > following >> > this logic. It could simply be an additional attribute with a >> > different >> > name. Or this new attribute could be a property of the block device >> > rather than the SCSI device, like NVMe does it >> > (/sys/block/nvme0n2/wwid). >> >> That's fine. I am not a big fan of the idea that block/foo/wwid and >> block/foo/device/wwid could end up being different. But I do think >> that >> from a userland tooling perspective the consistency with NVMe is more >> important. > > OK, then here's the plan: Change SCSI (block) device identification to > work similar to NVMe (in addition to what we have now). > > 1. add a new sysfs attribute for SCSI block devices as > /sys/block/sd$X/wwid, the value derived similar to the current "wwid" > SCSI device attribute, but using the same prio for SCSI name strings as > for their binary counterparts, as described above. > > 2. add "naa" and "eui" attributes, too, for user‑space applications > that are interested in these specific attributes. > Fixme: should we differentiate between different "naa" or eui subtypes, > like "naa_regext", "eui64" or similar? If the device defines multiple > "naa" designators, which one should we choose? > > 3. Change udev rules such that they primarily look at the attribute in > 1.) on new installments, and introduce a variable ID_LEGACY to tell the > rules to fall back to the current algorithm. I suppose it makes sense > to have at least ID_VENDOR and ID_PRODUCT available when making this > decision, so that it doesn't have to be a global setting on a given > host. > > While we're at it, I'd like to mention another issue: WWID changes. > > This is a big problem for multipathd. The gist is that the device > identification attributes in sysfs only change after rescanning the > device. Thus if a user changes LUN assignments on a storage system, > it can happen that a direct INQUIRY returns a different WWID as in > sysfs, which is fatal. If we plan to rely more on sysfs for device > identification in the future, the problem gets worse. I think many devices rely on the fact that they are identified by Vendor/model/serial_nr, because in most professional SAN storage systems you can pre-set the serial number to a custom value; so if you want a new disk (maybe a snapshot) to be compatible with the old one, just assign the same serial number. I guess that's the idea behind. > > I wonder if there's a chance that future kernels would automatically > update the attributes if a corresponding UNIT ATTENTION condition such > as INQUIRY DATA HAS CHANGED is received (*), or if we can find some > other way to avoid data corruption resulting from writing to the wrong > device. > > Regards, > Martin > > (*) I've been told that WWID changes can happen even without receiving > an UA. But in that case I'm inclined to put the blame on the storage. > > ‑‑ > Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 > SUSE Software Solutions Germany GmbH > HRB 36809, AG Nürnberg GF: Felix Imendörffer > > > _______________________________________________ > systemd‑devel mailing list > systemd‑devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd‑devel 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4E4EC433B4 for ; Mon, 26 Apr 2021 11:24:23 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7746A608FE for ; Mon, 26 Apr 2021 11:24:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7746A608FE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rz.uni-regensburg.de Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=dm-devel-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-347-BE_3AVoAPlyL7adxeNT62A-1; Mon, 26 Apr 2021 07:24:16 -0400 X-MC-Unique: BE_3AVoAPlyL7adxeNT62A-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9E8FB18397AD; Mon, 26 Apr 2021 11:24:10 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 936182BFC7; Mon, 26 Apr 2021 11:24:09 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 222081806D1A; Mon, 26 Apr 2021 11:24:07 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 13QBO3ew004486 for ; Mon, 26 Apr 2021 07:24:04 -0400 Received: by smtp.corp.redhat.com (Postfix) id EF829223033F; Mon, 26 Apr 2021 11:24:02 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E9BC220148E7 for ; Mon, 26 Apr 2021 11:24:00 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8863280158D for ; Mon, 26 Apr 2021 11:24:00 +0000 (UTC) Received: from mx4.uni-regensburg.de (mx4.uni-regensburg.de [194.94.157.149]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-357-1_5OZsymPlO7B9Y4ln3V_Q-1; Mon, 26 Apr 2021 07:23:56 -0400 X-MC-Unique: 1_5OZsymPlO7B9Y4ln3V_Q-1 Received: from mx4.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5FFAB600005E; Mon, 26 Apr 2021 13:15:00 +0200 (CEST) Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx4.uni-regensburg.de (Postfix) with ESMTP id 318AC600005B; Mon, 26 Apr 2021 13:15:00 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 26 Apr 2021 13:14:59 +0200 Message-Id: <6086A0B2020000A100040BBE@gwsmtp.uni-regensburg.de> Date: Mon, 26 Apr 2021 13:14:58 +0200 From: "Ulrich Windl" To: , References: <06489ea37311fe7bf73b27a41b5209ee4cca85fe.camel@suse.com> <685c40341d2ddef2fe5a54dd656d10104b0c1bfa.camel@suse.com> In-Reply-To: Mime-Version: 1.0 X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-MIME-Autoconverted: from quoted-printable to 8bit by lists01.pubmisc.prod.ext.phx2.redhat.com id 13QBO3ew004486 X-loop: dm-devel@redhat.com Cc: hare@suse.com, "systemd-devel@lists.freedesktop.org" , linux-scsi@vger.kernel.org, dm-devel@redhat.com, dgilbert@interlog.com, jejb@linux.vnet.ibm.com, hch@lst.de Subject: [dm-devel] Antw: [EXT] Re: [systemd-devel] RFC: one more time: SCSI device identification X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4+IE1hcnRpbiBXaWxjayA8bWFydGluLndpbGNrQHN1c2UuY29tPiBzY2hyaWViIGFtIDIzLjA0 LjIwMjEgdW0gMTI6MjggaW4KTmFjaHJpY2h0IDxlMzE4NDUwMWNiZjIzYWIwYWU5NGQ2NjQ3MjVl NzJiNjkzYzY0YmE5LmNhbWVsQHN1c2UuY29tPjoKPiBPbiBUaHUsIDIwMjHigJEwNOKAkTIyIGF0 IDIxOjQwIOKAkTA0MDAsIE1hcnRpbiBLLiBQZXRlcnNlbiB3cm90ZToKPj4gCj4+IE1hcnRpbiwK Pj4gCj4+ID4gSSBzdXBwb3NlIDk5LjklIG9mIHVzZXJzIG5ldmVyIGJvdGhlciB3aXRoIGN1c3Rv bWl6aW5nIHRoZSB1ZGV2Cj4+ID4gcnVsZXMuCj4+IAo+PiBFeGNlcHQgZm9yIHRoZSBvdGhlciA5 OS45JSwgcGVyaGFwcz8gOikgV2UgZGVmaW5pdGVseSBoYXZlIG1hbnkgdXNlcnMKPj4gdGhhdCB0 d2VhayB1ZGV2IHN0b3JhZ2UgcnVsZXMgZm9yIGEgdmFyaWV0eSBvZiByZWFzb25zLiBJbmNsdWRp bmcKPj4gYmVpbmcKPj4gYWJsZSB0byB1c2UgUklJIGZvciBMVU4gbmFtaW5nIHB1cnBvc2VzLgo+ PiAKPj4gPiBCdXQgd2UgY2FuIGFjdHVhbGx5IGNvbWJpbmUgYm90aCBhcHByb2FjaGVzLiBJZiAi d3dpZCIgeWllbGRzIGEKPj4gPiBnb29kCj4+ID4gdmFsdWUgbW9zdCBvZiB0aGUgdGltZSAod2hp Y2ggaXMgdHJ1ZSBJTU8pLCB3ZSBjb3VsZCBtYWtlIHVzZXIKPj4gPiBzcGFjZQo+PiA+IHJlbHkg b24gaXQgYnkgZGVmYXVsdCwgYW5kIG1ha2UgaXQgcG9zc2libGUgdG8gc2V0IGFuIHVkZXYgcHJv cGVydHkKPj4gPiAoZS5nLiBFTlZ7SURfTEVHQUNZfT0iMSIpIHRvIHRlbGwgdWRldiBydWxlcyB0 byBkZXRlcm1pbmUgV1dJRAo+PiA+IGRpZmZlcmVudGx5LiBVc2Vy4oCRc3BhY2UgYXBwcyBsaWtl IG11bHRpcGF0aCBjb3VsZCBjaGVjayB0aGUKPj4gPiBJRF9MRUdBQ1kKPj4gPiBwcm9wZXJ0eSB0 byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgcmVhZGluZyB0aGUgInd3aWQiIGF0dHJpYnV0ZQo+ PiA+IHdvdWxkCj4+ID4gYmUgY29uc2lzdGVudCB3aXRoIHVkZXYuIFRoYXQgd291bGQgc2ltcGxp ZnkgbWF0dGVycyBhIGxvdCBmb3IgdXMKPj4gPiAoQmVuLAo+PiA+IGRvIHlvdSBhZ3JlZT8pLCB3 aXRob3V0IHRoZSBuZWVkIG9mIGFkZGluZyBlbmRsZXNzIEJMSVNUIGVudHJpZXMuCj4+IAo+PiBU aGF0J3MgZmluZSB3aXRoIG1lLgo+PiAKPj4gPiBBRkFJQ1QsIG5vIG1ham9yIGRpc3RyaWJ1dGlv biB1c2VzICJ3d2lkIiBmb3IgdGhpcyBwdXJwb3NlICh5ZXQpLgo+PiAKPj4gV2UgZGVmaW5pdGVs eSBoYXZlIHVzZXJzIHRoYXQgY3VycmVudGx5IHJlbHkgb24gd3dpZCwgYWx0aG91Z2gKPj4gcHJv YmFibHkKPj4gbm90IHRocm91Z2ggc3RhbmRhcmQgZGlzdHJvIHNjcmlwdHMuCj4+IAo+PiA+IElu IGEgcmVjZW50IGRpc2N1c3Npb24gd2l0aCBIYW5uZXMsIHRoZSBpZGVhIGNhbWUgdXAgdGhhdCB0 aGUKPj4gPiBwcmlvcml0eQo+PiA+IG9mICJTQ1NJIG5hbWUgc3RyaW5nIiBkZXNpZ25hdG9ycyBz aG91bGQgYWN0dWFsbHkgZGVwZW5kIG9uIHRoZWlyCj4+ID4gc3VidHlwZS4gIm5hYS4iIG5hbWUg c3RyaW5ncyBzaG91bGQgbWFwIHRvIHRoZSByZXNwZWN0aXZlIE5BQQo+PiA+IGRlc2NyaXB0b3Jz LCBhbmQgImV1aS4iLCBsaWtld2lzZSAob25seSAiaXFuLiIgZGVzY3JpcHRvcnMgaGF2ZSBubwo+ PiA+IGJpbmFyeSBjb3VudGVycGFydDsgd2UgdGhvdWdodCB0aGV5IHNob3VsZCByYXRoZXIgYmUg cHV0IGJlbG93IE5BQSwKPj4gPiBwcmlv4oCRd2lzZSkuCj4+IAo+PiBJIGxpa2Ugd2hhdCBOVk1l IGRpZCB3cnQuIHRvIGV4cG9ydGluZyBldWksIG5ndWlkLCB1dWlkIHNlcGFyYXRlbHkKPj4gZnJv bQo+PiB0aGUgYmVzdOKAkWVmZm9ydCB3d2lkLiBUaGF0J3Mgd2h5IEkgc3VnZ2VzdGVkIHNlcGFy YXRlIHN5c2ZzIGZpbGVzIGZvcgo+PiB0aGUgdmFyaW91cyBwYWdlIDB4ODMgZGVzY3JpcHRvcnMu IEkgbGlrZSB0aGUgaWRlYSBvZiBiZWluZyBhYmxlIHRvCj4+IGV4cGxpY2l0bHkgYXNrIGZvciBh biBldWkgaWYgdGhhdCdzIHdoYXQgSSBuZWVkLiBCdXQgdGhhdCBhcHBlYXJzIHRvCj4+IGJlCj4+ IHNvbWV3aGF0IG9ydGhvZ29uYWwgdG8geW91ciByZXF1ZXN0Lgo+PiAKPj4gPiBJIHdvbmRlciBp ZiB5b3UnZCBhZ3JlZSB3aXRoIGEgY2hhbmdlIG1hZGUgdGhhdCB3YXkgZm9yICJ3d2lkIi4gSQo+ PiA+IHN1cHBvc2UgeW91IGRvbid0LiBJJ2QgdGhlbiBwcm9wb3NlIHRvIGFkZCBhIG5ldyBhdHRy aWJ1dGUKPj4gPiBmb2xsb3dpbmcKPj4gPiB0aGlzIGxvZ2ljLiBJdCBjb3VsZCBzaW1wbHkgYmUg YW4gYWRkaXRpb25hbCBhdHRyaWJ1dGUgd2l0aCBhCj4+ID4gZGlmZmVyZW50Cj4+ID4gbmFtZS4g T3IgdGhpcyBuZXcgYXR0cmlidXRlIGNvdWxkIGJlIGEgcHJvcGVydHkgb2YgdGhlIGJsb2NrIGRl dmljZQo+PiA+IHJhdGhlciB0aGFuIHRoZSBTQ1NJIGRldmljZSwgbGlrZSBOVk1lIGRvZXMgaXQK Pj4gPiAoL3N5cy9ibG9jay9udm1lMG4yL3d3aWQpLgo+PiAKPj4gVGhhdCdzIGZpbmUuIEkgYW0g bm90IGEgYmlnIGZhbiBvZiB0aGUgaWRlYSB0aGF0IGJsb2NrL2Zvby93d2lkIGFuZAo+PiBibG9j ay9mb28vZGV2aWNlL3d3aWQgY291bGQgZW5kIHVwIGJlaW5nIGRpZmZlcmVudC4gQnV0IEkgZG8g dGhpbmsKPj4gdGhhdAo+PiBmcm9tIGEgdXNlcmxhbmQgdG9vbGluZyBwZXJzcGVjdGl2ZSB0aGUg Y29uc2lzdGVuY3kgd2l0aCBOVk1lIGlzIG1vcmUKPj4gaW1wb3J0YW50Lgo+IAo+IE9LLCB0aGVu IGhlcmUncyB0aGUgcGxhbjogQ2hhbmdlIFNDU0kgKGJsb2NrKSBkZXZpY2UgaWRlbnRpZmljYXRp b24gdG8KPiB3b3JrIHNpbWlsYXIgdG8gTlZNZSAoaW4gYWRkaXRpb24gdG8gd2hhdCB3ZSBoYXZl IG5vdykuCj4gCj4gIDEuIGFkZCBhIG5ldyBzeXNmcyBhdHRyaWJ1dGUgZm9yIFNDU0kgYmxvY2sg ZGV2aWNlcyBhcwo+IC9zeXMvYmxvY2svc2QkWC93d2lkLCB0aGUgdmFsdWUgZGVyaXZlZCBzaW1p bGFyIHRvIHRoZSBjdXJyZW50ICJ3d2lkIgo+IFNDU0kgZGV2aWNlIGF0dHJpYnV0ZSwgYnV0IHVz aW5nIHRoZSBzYW1lIHByaW8gZm9yIFNDU0kgbmFtZSBzdHJpbmdzIGFzCj4gZm9yIHRoZWlyIGJp bmFyeSBjb3VudGVycGFydHMsIGFzIGRlc2NyaWJlZCBhYm92ZS4KPiAKPiAgMi4gYWRkICJuYWEi IGFuZCAiZXVpIiBhdHRyaWJ1dGVzLCB0b28sIGZvciB1c2Vy4oCRc3BhY2UgYXBwbGljYXRpb25z Cj4gdGhhdCBhcmUgaW50ZXJlc3RlZCBpbiB0aGVzZSBzcGVjaWZpYyBhdHRyaWJ1dGVzLiAKPiBG aXhtZTogc2hvdWxkIHdlIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBkaWZmZXJlbnQgIm5hYSIgb3Ig ZXVpIHN1YnR5cGVzLAo+IGxpa2UgIm5hYV9yZWdleHQiLCAiZXVpNjQiIG9yIHNpbWlsYXI/IElm IHRoZSBkZXZpY2UgZGVmaW5lcyBtdWx0aXBsZQo+ICJuYWEiIGRlc2lnbmF0b3JzLCB3aGljaCBv bmUgc2hvdWxkIHdlIGNob29zZT8KPiAKPiAgMy4gQ2hhbmdlIHVkZXYgcnVsZXMgc3VjaCB0aGF0 IHRoZXkgcHJpbWFyaWx5IGxvb2sgYXQgdGhlIGF0dHJpYnV0ZSBpbgo+IDEuKSBvbiBuZXcgaW5z dGFsbG1lbnRzLCBhbmQgaW50cm9kdWNlIGEgdmFyaWFibGUgSURfTEVHQUNZIHRvIHRlbGwgdGhl Cj4gcnVsZXMgdG8gZmFsbCBiYWNrIHRvIHRoZSBjdXJyZW50IGFsZ29yaXRobS4gSSBzdXBwb3Nl IGl0IG1ha2VzIHNlbnNlCj4gdG8gaGF2ZSBhdCBsZWFzdCBJRF9WRU5ET1IgYW5kIElEX1BST0RV Q1QgYXZhaWxhYmxlIHdoZW4gbWFraW5nIHRoaXMKPiBkZWNpc2lvbiwgc28gdGhhdCBpdCBkb2Vz bid0IGhhdmUgdG8gYmUgYSBnbG9iYWwgc2V0dGluZyBvbiBhIGdpdmVuCj4gaG9zdC4KPiAKPiBX aGlsZSB3ZSdyZSBhdCBpdCwgSSdkIGxpa2UgdG8gbWVudGlvbiBhbm90aGVyIGlzc3VlOiBXV0lE IGNoYW5nZXMuCj4gCj4gVGhpcyBpcyBhIGJpZyBwcm9ibGVtIGZvciBtdWx0aXBhdGhkLiBUaGUg Z2lzdCBpcyB0aGF0IHRoZSBkZXZpY2UKPiBpZGVudGlmaWNhdGlvbiBhdHRyaWJ1dGVzIGluIHN5 c2ZzIG9ubHkgY2hhbmdlIGFmdGVyIHJlc2Nhbm5pbmcgdGhlCj4gZGV2aWNlLiBUaHVzIGlmIGEg dXNlciBjaGFuZ2VzIExVTiBhc3NpZ25tZW50cyBvbiBhIHN0b3JhZ2Ugc3lzdGVtLCAKPiBpdCBj YW4gaGFwcGVuIHRoYXQgYSBkaXJlY3QgSU5RVUlSWSByZXR1cm5zIGEgZGlmZmVyZW50IFdXSUQg YXMgaW4KPiBzeXNmcywgd2hpY2ggaXMgZmF0YWwuIElmIHdlIHBsYW4gdG8gcmVseSBtb3JlIG9u IHN5c2ZzIGZvciBkZXZpY2UKPiBpZGVudGlmaWNhdGlvbiBpbiB0aGUgZnV0dXJlLCB0aGUgcHJv YmxlbSBnZXRzIHdvcnNlLiAKCkkgdGhpbmsgbWFueSBkZXZpY2VzIHJlbHkgb24gdGhlIGZhY3Qg dGhhdCB0aGV5IGFyZSBpZGVudGlmaWVkIGJ5ClZlbmRvci9tb2RlbC9zZXJpYWxfbnIsIGJlY2F1 c2UgaW4gbW9zdCBwcm9mZXNzaW9uYWwgU0FOIHN0b3JhZ2Ugc3lzdGVtcyB5b3UKY2FuIHByZS1z ZXQgdGhlIHNlcmlhbCBudW1iZXIgdG8gYSBjdXN0b20gdmFsdWU7IHNvIGlmIHlvdSB3YW50IGEg bmV3IGRpc2sKKG1heWJlIGEgc25hcHNob3QpIHRvIGJlIGNvbXBhdGlibGUgd2l0aCB0aGUgb2xk IG9uZSwganVzdCBhc3NpZ24gdGhlIHNhbWUKc2VyaWFsIG51bWJlci4gSSBndWVzcyB0aGF0J3Mg dGhlIGlkZWEgYmVoaW5kLgoKPiAKPiBJIHdvbmRlciBpZiB0aGVyZSdzIGEgY2hhbmNlIHRoYXQg ZnV0dXJlIGtlcm5lbHMgd291bGQgYXV0b21hdGljYWxseQo+IHVwZGF0ZSB0aGUgYXR0cmlidXRl cyBpZiBhIGNvcnJlc3BvbmRpbmcgVU5JVCBBVFRFTlRJT04gY29uZGl0aW9uIHN1Y2gKPiBhcyBJ TlFVSVJZIERBVEEgSEFTIENIQU5HRUQgaXMgcmVjZWl2ZWQgKCopLCBvciBpZiB3ZSBjYW4gZmlu ZCBzb21lCj4gb3RoZXIgd2F5IHRvIGF2b2lkIGRhdGEgY29ycnVwdGlvbiByZXN1bHRpbmcgZnJv bSB3cml0aW5nIHRvIHRoZSB3cm9uZwo+IGRldmljZS4KPiAKPiBSZWdhcmRzLAo+IE1hcnRpbgo+ IAo+ICgqKSBJJ3ZlIGJlZW4gdG9sZCB0aGF0IFdXSUQgY2hhbmdlcyBjYW4gaGFwcGVuIGV2ZW4g d2l0aG91dCByZWNlaXZpbmcKPiBhbiBVQS4gQnV0IGluIHRoYXQgY2FzZSBJJ20gaW5jbGluZWQg dG8gcHV0IHRoZSBibGFtZSBvbiB0aGUgc3RvcmFnZS4KPiAKPiDigJHigJEgCj4gRHIuIE1hcnRp biBXaWxjayA8bXdpbGNrQHN1c2UuY29tPiwgVGVsLiArNDkgKDApOTExIDc0MDUzIDIxMDcKPiBT VVNFIFNvZnR3YXJlIFNvbHV0aW9ucyBHZXJtYW55IEdtYkgKPiBIUkIgMzY4MDksIEFHIE7DvHJu YmVyZyBHRjogRmVsaXggSW1lbmTDtnJmZmVyCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBzeXN0ZW1k4oCRZGV2ZWwgbWFpbGluZyBsaXN0 Cj4gc3lzdGVtZOKAkWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZyAKPiBodHRwczovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N5c3RlbWTigJFkZXZlbCAKCgoKCi0t CmRtLWRldmVsIG1haWxpbmcgbGlzdApkbS1kZXZlbEByZWRoYXQuY29tCmh0dHBzOi8vbGlzdG1h bi5yZWRoYXQuY29tL21haWxtYW4vbGlzdGluZm8vZG0tZGV2ZWw=