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=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 DF4E9C282D7 for ; Sun, 3 Feb 2019 02:47:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B0C6A20870 for ; Sun, 3 Feb 2019 02:47:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KdTP3ifq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727264AbfBCCrd (ORCPT ); Sat, 2 Feb 2019 21:47:33 -0500 Received: from mail-it1-f193.google.com ([209.85.166.193]:56207 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726738AbfBCCrd (ORCPT ); Sat, 2 Feb 2019 21:47:33 -0500 Received: by mail-it1-f193.google.com with SMTP id m62so15601904ith.5; Sat, 02 Feb 2019 18:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZMYtRmKOONVnZU74jVMCYosr4pKhEho8RsInAYHkIrU=; b=KdTP3ifqajYxvYkJWRnrvGBZSyEmIgYA39UHfnYk43VDQd72q/DV+y/VS2iwKEvIkD mRWvndEEKv+NBrz/qbRD85E925sBQ+IdLiJtyf/bxgXkDN+2I4U/UbTP3ge/SkftkHvi GGUUf6ZdBiWJsU2bA6GkH0nb4DRfPa+pYyD98P75tcaruSBdAeaHiVtmv6LUWquk0sOv XzMaN1E0rPVqGlR/n3j6dgNpYZCtUWuTmavMClfuH1J0jVhRwgSzMOLwALcUqNtOBph7 t1pfsH7SLZ1Gu0xrDf7kQL91744p180NWBVbA7IAICl1QNu57omX10tU5p7iajd7hCz1 2EHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZMYtRmKOONVnZU74jVMCYosr4pKhEho8RsInAYHkIrU=; b=It0anNRW9lg6qUEkUu8yMgiAqPFk+lcdoUrFtkP7bg4gmWeb6FVE/lmlhhr97x93uM SkoOGAmdh8+zgDAA5PSeJSekjXWctZqi89DTiQAxaEKgQfy8TNYxSGSTIl3RmWYotYp1 HIUiWoCr5TvvZK5sYKrIDD3sPyP7CrTDG7x1H7MzpTCUEHpHPqRW67/WrZOwM7z2BmYF 8rbTAWIAlaGVE65lnOcavWeG1NgD6/gGAGSBcXaWE/E8c5A9cbmI4Dug8G3tTGbfEskA P3+sGr4T4BuLcXRVV20F6F1P1tBqzkmCcBZUBCqLo4mQyPDFTAR5aLYszCiNUumexWZ1 k9Ug== X-Gm-Message-State: AHQUAuY6g2eCLtJ4Be+vktu3Bw0hUNOSvvmSj+NGEH83GqrAe0mFGTfM u8XBS0OAZFDsPyU9m2Le09X/N9lKRLWDO8cz0G0= X-Google-Smtp-Source: AHgI3IYS2NBXv2myRee69tHGYtSoIzUX3ZpjIGORvAD+gSqnvHnb8wwPrS8ntV2W3anTchzcRl2E0ikoXcP4hPviPoE= X-Received: by 2002:a24:3dd1:: with SMTP id n200mr5846603itn.61.1549162051879; Sat, 02 Feb 2019 18:47:31 -0800 (PST) MIME-Version: 1.0 References: <20190202153454.7121-1-deepa.kernel@gmail.com> <20190202153454.7121-13-deepa.kernel@gmail.com> <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> In-Reply-To: <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> From: Deepa Dinamani Date: Sat, 2 Feb 2019 18:47:20 -0800 Message-ID: Subject: Re: [PATCH net-next v5 12/12] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW To: Oliver Hartkopp Cc: "David S. Miller" , Linux Kernel Mailing List , Linux Network Devel Mailing List , Arnd Bergmann , y2038 Mailman List , ccaulfie@redhat.com, Helge Deller , Paul Mackerras , Ralf Baechle , Richard Henderson , cluster-devel , linuxppc-dev , linux-alpha@vger.kernel.org, linux-arch , linux-mips@vger.kernel.org, Parisc List , sparclinux Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On Sat, Feb 2, 2019 at 9:15 AM Oliver Hartkopp wro= te: > > Hi all, > > On 02.02.19 16:34, Deepa Dinamani wrote: > > Add new socket timeout options that are y2038 safe. > (..) > > > > diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/= uapi/asm/socket.h > > index 9826d1db71d0..0d0fddb7e738 100644 > > --- a/arch/alpha/include/uapi/asm/socket.h > > +++ b/arch/alpha/include/uapi/asm/socket.h > > @@ -119,19 +119,25 @@ > > #define SO_TIMESTAMPNS_NEW 64 > > #define SO_TIMESTAMPING_NEW 65 > > > > -#if !defined(__KERNEL__) > > +#define SO_RCVTIMEO_NEW 66 > > +#define SO_SNDTIMEO_NEW 67 > > > > -#define SO_RCVTIMEO SO_RCVTIMEO_OLD > > -#define SO_SNDTIMEO SO_SNDTIMEO_OLD > > +#if !defined(__KERNEL__) > > > > #if __BITS_PER_LONG =3D=3D 64 > > #define SO_TIMESTAMP SO_TIMESTAMP_OLD > > #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD > > #define SO_TIMESTAMPING SO_TIMESTAMPING_OLD > > + > > +#define SO_RCVTIMEO SO_RCVTIMEO_OLD > > +#define SO_SNDTIMEO SO_SNDTIMEO_OLD > > Maybe I'm a bit late in this discussion as you are already in v5 ... > > I can see patches making the transition in different steps where it > might be helpful to name them *_OLD and *_NEW to understand the patches. > > But in the end the naming stays in the kernel for a very long time and I > remember myself (in early years) to name things 'new', 'new2', 'new3'. > > In fact SO_TIMESTAMP_OLD should be named SO_TIMESTAMP32 and > SO_TIMESTAMP_NEW should be named SO_TIMESTAMP64. Hmm. SO_TIMESTAMP_OLD uses 64-bit time_t on a 64 bit machine. In fact, there is no difference between the two options on a 64 bit machine. So using SO_TIMESTAMP_32 is just wrong. Likewise, SO_TIMESTAMP_64 naming somehow indicates that the existing one was not, and that is also not true on a 64-bit machine. Further, userspace will still continue to use SO_TIMESTAMP and the macros take care of which option to select internally. Moreover, these macros have been there for more than ten years (introduced before 2.4) and there has been no change. I doubt you will ever have NEW2. I think this argument is similar to saying don=E2=80=99t name these macros SO_TIMESTAMP because there might be SO_TIMESTAMP1 some day. There is never a perfect name. SO_TIMESTAMPING is also not really descriptive. > Especially as it tells you what is 'inside', the naming of these new intr= oduced constants should be replaced with *32 and *64 names. > The documentation and the other comments still fit perfectly then. I would prefer not to do this, for reasons mentioned above. Since you point out that it is easier to use this naming for intermediate steps, I suggest that we leave the series as it is. If you feel strongly to post a follow-on renaming patch, you could discuss it with the subsystem maintainers, if you think there is a correct but more descriptive naming. -Deepa > Regards, > Oliver From mboxrd@z Thu Jan 1 00:00:00 1970 From: Deepa Dinamani Subject: Re: [PATCH net-next v5 12/12] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW Date: Sat, 2 Feb 2019 18:47:20 -0800 Message-ID: References: <20190202153454.7121-1-deepa.kernel@gmail.com> <20190202153454.7121-13-deepa.kernel@gmail.com> <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: y2038-bounces@lists.linaro.org Sender: "Y2038" To: Oliver Hartkopp Cc: linux-arch , Parisc List , Arnd Bergmann , y2038 Mailman List , Linux Network Devel Mailing List , Helge Deller , Linux Kernel Mailing List , Ralf Baechle , linux-mips@vger.kernel.org, cluster-devel , ccaulfie@redhat.com, Paul Mackerras , linux-alpha@vger.kernel.org, sparclinux , linuxppc-dev , "David S. Miller" , Richard Henderson List-Id: linux-arch.vger.kernel.org T24gU2F0LCBGZWIgMiwgMjAxOSBhdCA5OjE1IEFNIE9saXZlciBIYXJ0a29wcCA8c29ja2V0Y2Fu QGhhcnRrb3BwLm5ldD4gd3JvdGU6Cj4KPiBIaSBhbGwsCj4KPiBPbiAwMi4wMi4xOSAxNjozNCwg RGVlcGEgRGluYW1hbmkgd3JvdGU6Cj4gPiBBZGQgbmV3IHNvY2tldCB0aW1lb3V0IG9wdGlvbnMg dGhhdCBhcmUgeTIwMzggc2FmZS4KPiAoLi4pCj4gPgo+ID4gZGlmZiAtLWdpdCBhL2FyY2gvYWxw aGEvaW5jbHVkZS91YXBpL2FzbS9zb2NrZXQuaCBiL2FyY2gvYWxwaGEvaW5jbHVkZS91YXBpL2Fz bS9zb2NrZXQuaAo+ID4gaW5kZXggOTgyNmQxZGI3MWQwLi4wZDBmZGRiN2U3MzggMTAwNjQ0Cj4g PiAtLS0gYS9hcmNoL2FscGhhL2luY2x1ZGUvdWFwaS9hc20vc29ja2V0LmgKPiA+ICsrKyBiL2Fy Y2gvYWxwaGEvaW5jbHVkZS91YXBpL2FzbS9zb2NrZXQuaAo+ID4gQEAgLTExOSwxOSArMTE5LDI1 IEBACj4gPiAgICNkZWZpbmUgU09fVElNRVNUQU1QTlNfTkVXICAgICAgNjQKPiA+ICAgI2RlZmlu ZSBTT19USU1FU1RBTVBJTkdfTkVXICAgICA2NQo+ID4KPiA+IC0jaWYgIWRlZmluZWQoX19LRVJO RUxfXykKPiA+ICsjZGVmaW5lIFNPX1JDVlRJTUVPX05FVyAgICAgICAgIDY2Cj4gPiArI2RlZmlu ZSBTT19TTkRUSU1FT19ORVcgICAgICAgICA2Nwo+ID4KPiA+IC0jZGVmaW5lICAgICAgU09fUkNW VElNRU8gU09fUkNWVElNRU9fT0xECj4gPiAtI2RlZmluZSAgICAgIFNPX1NORFRJTUVPIFNPX1NO RFRJTUVPX09MRAo+ID4gKyNpZiAhZGVmaW5lZChfX0tFUk5FTF9fKQo+ID4KPiA+ICAgI2lmIF9f QklUU19QRVJfTE9ORyA9PSA2NAo+ID4gICAjZGVmaW5lIFNPX1RJTUVTVEFNUCAgICAgICAgICAg ICAgICBTT19USU1FU1RBTVBfT0xECj4gPiAgICNkZWZpbmUgU09fVElNRVNUQU1QTlMgICAgICAg ICAgICAgIFNPX1RJTUVTVEFNUE5TX09MRAo+ID4gICAjZGVmaW5lIFNPX1RJTUVTVEFNUElORyAg ICAgICAgIFNPX1RJTUVTVEFNUElOR19PTEQKPiA+ICsKPiA+ICsjZGVmaW5lIFNPX1JDVlRJTUVP ICAgICAgICAgIFNPX1JDVlRJTUVPX09MRAo+ID4gKyNkZWZpbmUgU09fU05EVElNRU8gICAgICAg ICAgU09fU05EVElNRU9fT0xECj4KPiBNYXliZSBJJ20gYSBiaXQgbGF0ZSBpbiB0aGlzIGRpc2N1 c3Npb24gYXMgeW91IGFyZSBhbHJlYWR5IGluIHY1IC4uLgo+Cj4gSSBjYW4gc2VlIHBhdGNoZXMg bWFraW5nIHRoZSB0cmFuc2l0aW9uIGluIGRpZmZlcmVudCBzdGVwcyB3aGVyZSBpdAo+IG1pZ2h0 IGJlIGhlbHBmdWwgdG8gbmFtZSB0aGVtICpfT0xEIGFuZCAqX05FVyB0byB1bmRlcnN0YW5kIHRo ZSBwYXRjaGVzLgo+Cj4gQnV0IGluIHRoZSBlbmQgdGhlIG5hbWluZyBzdGF5cyBpbiB0aGUga2Vy bmVsIGZvciBhIHZlcnkgbG9uZyB0aW1lIGFuZCBJCj4gcmVtZW1iZXIgbXlzZWxmIChpbiBlYXJs eSB5ZWFycykgdG8gbmFtZSB0aGluZ3MgJ25ldycsICduZXcyJywgJ25ldzMnLgo+Cj4gSW4gZmFj dCBTT19USU1FU1RBTVBfT0xEIHNob3VsZCBiZSBuYW1lZCBTT19USU1FU1RBTVAzMiBhbmQKPiBT T19USU1FU1RBTVBfTkVXIHNob3VsZCBiZSBuYW1lZCBTT19USU1FU1RBTVA2NC4KCkhtbS4gU09f VElNRVNUQU1QX09MRCB1c2VzIDY0LWJpdCB0aW1lX3Qgb24gYSA2NCBiaXQgbWFjaGluZS4gSW4g ZmFjdCwKdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gb3B0aW9ucyBvbiBh IDY0IGJpdCBtYWNoaW5lLiBTbwp1c2luZyAgU09fVElNRVNUQU1QXzMyIGlzIGp1c3Qgd3Jvbmcu CgpMaWtld2lzZSwgU09fVElNRVNUQU1QXzY0IG5hbWluZyBzb21laG93IGluZGljYXRlcyB0aGF0 IHRoZSBleGlzdGluZwpvbmUgd2FzIG5vdCwgYW5kIHRoYXQgaXMgYWxzbyBub3QgdHJ1ZSBvbiBh IDY0LWJpdCBtYWNoaW5lLgoKRnVydGhlciwgdXNlcnNwYWNlIHdpbGwgc3RpbGwgY29udGludWUg dG8gdXNlIFNPX1RJTUVTVEFNUCBhbmQgdGhlCm1hY3JvcyB0YWtlIGNhcmUgb2Ygd2hpY2ggb3B0 aW9uIHRvIHNlbGVjdCBpbnRlcm5hbGx5LgoKTW9yZW92ZXIsIHRoZXNlIG1hY3JvcyBoYXZlIGJl ZW4gdGhlcmUgZm9yIG1vcmUgdGhhbiB0ZW4geWVhcnMKKGludHJvZHVjZWQgYmVmb3JlIDIuNCkg YW5kIHRoZXJlIGhhcyBiZWVuIG5vIGNoYW5nZS4gSSBkb3VidCB5b3Ugd2lsbApldmVyIGhhdmUg TkVXMi4KSSB0aGluayB0aGlzIGFyZ3VtZW50IGlzIHNpbWlsYXIgdG8gc2F5aW5nIGRvbuKAmXQg bmFtZSB0aGVzZSBtYWNyb3MKU09fVElNRVNUQU1QIGJlY2F1c2UgdGhlcmUgbWlnaHQgYmUgU09f VElNRVNUQU1QMSBzb21lIGRheS4gVGhlcmUgaXMKbmV2ZXIgYSBwZXJmZWN0IG5hbWUuIFNPX1RJ TUVTVEFNUElORyBpcyBhbHNvIG5vdCByZWFsbHkgZGVzY3JpcHRpdmUuCgo+IEVzcGVjaWFsbHkg YXMgaXQgdGVsbHMgeW91IHdoYXQgaXMgJ2luc2lkZScsIHRoZSBuYW1pbmcgb2YgdGhlc2UgbmV3 IGludHJvZHVjZWQgY29uc3RhbnRzIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoICozMiBhbmQgKjY0 IG5hbWVzLgo+IFRoZSBkb2N1bWVudGF0aW9uIGFuZCB0aGUgb3RoZXIgY29tbWVudHMgc3RpbGwg Zml0IHBlcmZlY3RseSB0aGVuLgoKSSB3b3VsZCBwcmVmZXIgbm90IHRvIGRvIHRoaXMsIGZvciBy ZWFzb25zIG1lbnRpb25lZCBhYm92ZS4gU2luY2UgeW91CnBvaW50IG91dCB0aGF0IGl0IGlzIGVh c2llciB0byB1c2UgdGhpcyBuYW1pbmcgZm9yIGludGVybWVkaWF0ZSBzdGVwcywKSSBzdWdnZXN0 IHRoYXQgd2UgbGVhdmUgdGhlIHNlcmllcyBhcyBpdCBpcy4KSWYgeW91IGZlZWwgc3Ryb25nbHkg dG8gcG9zdCBhIGZvbGxvdy1vbiByZW5hbWluZyBwYXRjaCwgeW91IGNvdWxkCmRpc2N1c3MgaXQg d2l0aCB0aGUgc3Vic3lzdGVtIG1haW50YWluZXJzLCBpZiB5b3UgdGhpbmsgdGhlcmUgaXMgYQpj b3JyZWN0IGJ1dCBtb3JlIGRlc2NyaXB0aXZlIG5hbWluZy4KCi1EZWVwYQoKPiBSZWdhcmRzLAo+ IE9saXZlcgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpZ MjAzOCBtYWlsaW5nIGxpc3QKWTIwMzhAbGlzdHMubGluYXJvLm9yZwpodHRwczovL2xpc3RzLmxp bmFyby5vcmcvbWFpbG1hbi9saXN0aW5mby95MjAzOAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Deepa Dinamani Date: Sun, 03 Feb 2019 02:47:20 +0000 Subject: Re: [PATCH net-next v5 12/12] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW Message-Id: List-Id: References: <20190202153454.7121-1-deepa.kernel@gmail.com> <20190202153454.7121-13-deepa.kernel@gmail.com> <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> In-Reply-To: <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: Oliver Hartkopp Cc: linux-arch , Parisc List , Arnd Bergmann , y2038 Mailman List , Linux Network Devel Mailing List , Helge Deller , Linux Kernel Mailing List , Ralf Baechle , linux-mips@vger.kernel.org, cluster-devel , ccaulfie@redhat.com, Paul Mackerras , linux-alpha@vger.kernel.org, sparclinux , linuxppc-dev , "David S. Miller" , Richard Henderson On Sat, Feb 2, 2019 at 9:15 AM Oliver Hartkopp wro= te: > > Hi all, > > On 02.02.19 16:34, Deepa Dinamani wrote: > > Add new socket timeout options that are y2038 safe. > (..) > > > > diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/= uapi/asm/socket.h > > index 9826d1db71d0..0d0fddb7e738 100644 > > --- a/arch/alpha/include/uapi/asm/socket.h > > +++ b/arch/alpha/include/uapi/asm/socket.h > > @@ -119,19 +119,25 @@ > > #define SO_TIMESTAMPNS_NEW 64 > > #define SO_TIMESTAMPING_NEW 65 > > > > -#if !defined(__KERNEL__) > > +#define SO_RCVTIMEO_NEW 66 > > +#define SO_SNDTIMEO_NEW 67 > > > > -#define SO_RCVTIMEO SO_RCVTIMEO_OLD > > -#define SO_SNDTIMEO SO_SNDTIMEO_OLD > > +#if !defined(__KERNEL__) > > > > #if __BITS_PER_LONG =3D=3D 64 > > #define SO_TIMESTAMP SO_TIMESTAMP_OLD > > #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD > > #define SO_TIMESTAMPING SO_TIMESTAMPING_OLD > > + > > +#define SO_RCVTIMEO SO_RCVTIMEO_OLD > > +#define SO_SNDTIMEO SO_SNDTIMEO_OLD > > Maybe I'm a bit late in this discussion as you are already in v5 ... > > I can see patches making the transition in different steps where it > might be helpful to name them *_OLD and *_NEW to understand the patches. > > But in the end the naming stays in the kernel for a very long time and I > remember myself (in early years) to name things 'new', 'new2', 'new3'. > > In fact SO_TIMESTAMP_OLD should be named SO_TIMESTAMP32 and > SO_TIMESTAMP_NEW should be named SO_TIMESTAMP64. Hmm. SO_TIMESTAMP_OLD uses 64-bit time_t on a 64 bit machine. In fact, there is no difference between the two options on a 64 bit machine. So using SO_TIMESTAMP_32 is just wrong. Likewise, SO_TIMESTAMP_64 naming somehow indicates that the existing one was not, and that is also not true on a 64-bit machine. Further, userspace will still continue to use SO_TIMESTAMP and the macros take care of which option to select internally. Moreover, these macros have been there for more than ten years (introduced before 2.4) and there has been no change. I doubt you will ever have NEW2. I think this argument is similar to saying don=E2=80=99t name these macros SO_TIMESTAMP because there might be SO_TIMESTAMP1 some day. There is never a perfect name. SO_TIMESTAMPING is also not really descriptive. > Especially as it tells you what is 'inside', the naming of these new intr= oduced constants should be replaced with *32 and *64 names. > The documentation and the other comments still fit perfectly then. I would prefer not to do this, for reasons mentioned above. Since you point out that it is easier to use this naming for intermediate steps, I suggest that we leave the series as it is. If you feel strongly to post a follow-on renaming patch, you could discuss it with the subsystem maintainers, if you think there is a correct but more descriptive naming. -Deepa > Regards, > Oliver 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.7 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable 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 788B4C282D7 for ; Sun, 3 Feb 2019 02:49:13 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 9D61B2084A for ; Sun, 3 Feb 2019 02:49:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KdTP3ifq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D61B2084A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 43sZzp0gCHzDqJR for ; Sun, 3 Feb 2019 13:49:10 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::142; helo=mail-it1-x142.google.com; envelope-from=deepa.kernel@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="KdTP3ifq"; dkim-atps=neutral Received: from mail-it1-x142.google.com (mail-it1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 43sZxy1RwFzDqHV for ; Sun, 3 Feb 2019 13:47:33 +1100 (AEDT) Received: by mail-it1-x142.google.com with SMTP id m62so15601903ith.5 for ; Sat, 02 Feb 2019 18:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZMYtRmKOONVnZU74jVMCYosr4pKhEho8RsInAYHkIrU=; b=KdTP3ifqajYxvYkJWRnrvGBZSyEmIgYA39UHfnYk43VDQd72q/DV+y/VS2iwKEvIkD mRWvndEEKv+NBrz/qbRD85E925sBQ+IdLiJtyf/bxgXkDN+2I4U/UbTP3ge/SkftkHvi GGUUf6ZdBiWJsU2bA6GkH0nb4DRfPa+pYyD98P75tcaruSBdAeaHiVtmv6LUWquk0sOv XzMaN1E0rPVqGlR/n3j6dgNpYZCtUWuTmavMClfuH1J0jVhRwgSzMOLwALcUqNtOBph7 t1pfsH7SLZ1Gu0xrDf7kQL91744p180NWBVbA7IAICl1QNu57omX10tU5p7iajd7hCz1 2EHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZMYtRmKOONVnZU74jVMCYosr4pKhEho8RsInAYHkIrU=; b=e9liDECujtpmWbIRonLXLfGG4LKGn1PKULFbHLX3grvH75GqqX02EV0TSNrHGczdMi iut5XPvkIag4MXs/hFBaRBVtVckuJEVOF6L8HGu9C51d9/aa2LCnAj7+l2OeFeybe1Gc On6RCW/5mR47mGlVHEbyigRLmwqFBj90HwtzUkxHIh4ziqzNVvNKqMhhvKKcpTlwS5NV G8US/lp/iUk4j5YkFBfsULbSckudiexy3rd93KIwxP1oWXpMf8zWRUcQuWsLJYRCnjxO +LPhjk5fwae5DwAbLo4WABbiEte/IqDGmNc+r8nuYV94AR/jEuO6+NynJsTTZPdic3DQ Y4wQ== X-Gm-Message-State: AHQUAua8EgoHJtm8z64QN2scCpaGY1Cj7/iCQdXkoa/BPA1jouHsMMtg VRxLT9V1WyFFak7NKIEHj9d4p6Ufrll1Pwn34JE= X-Google-Smtp-Source: AHgI3IYS2NBXv2myRee69tHGYtSoIzUX3ZpjIGORvAD+gSqnvHnb8wwPrS8ntV2W3anTchzcRl2E0ikoXcP4hPviPoE= X-Received: by 2002:a24:3dd1:: with SMTP id n200mr5846603itn.61.1549162051879; Sat, 02 Feb 2019 18:47:31 -0800 (PST) MIME-Version: 1.0 References: <20190202153454.7121-1-deepa.kernel@gmail.com> <20190202153454.7121-13-deepa.kernel@gmail.com> <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> In-Reply-To: <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> From: Deepa Dinamani Date: Sat, 2 Feb 2019 18:47:20 -0800 Message-ID: Subject: Re: [PATCH net-next v5 12/12] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW To: Oliver Hartkopp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch , Parisc List , Arnd Bergmann , y2038 Mailman List , Linux Network Devel Mailing List , Helge Deller , Linux Kernel Mailing List , Ralf Baechle , linux-mips@vger.kernel.org, cluster-devel , ccaulfie@redhat.com, Paul Mackerras , linux-alpha@vger.kernel.org, sparclinux , linuxppc-dev , "David S. Miller" , Richard Henderson Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Sat, Feb 2, 2019 at 9:15 AM Oliver Hartkopp wro= te: > > Hi all, > > On 02.02.19 16:34, Deepa Dinamani wrote: > > Add new socket timeout options that are y2038 safe. > (..) > > > > diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/= uapi/asm/socket.h > > index 9826d1db71d0..0d0fddb7e738 100644 > > --- a/arch/alpha/include/uapi/asm/socket.h > > +++ b/arch/alpha/include/uapi/asm/socket.h > > @@ -119,19 +119,25 @@ > > #define SO_TIMESTAMPNS_NEW 64 > > #define SO_TIMESTAMPING_NEW 65 > > > > -#if !defined(__KERNEL__) > > +#define SO_RCVTIMEO_NEW 66 > > +#define SO_SNDTIMEO_NEW 67 > > > > -#define SO_RCVTIMEO SO_RCVTIMEO_OLD > > -#define SO_SNDTIMEO SO_SNDTIMEO_OLD > > +#if !defined(__KERNEL__) > > > > #if __BITS_PER_LONG =3D=3D 64 > > #define SO_TIMESTAMP SO_TIMESTAMP_OLD > > #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD > > #define SO_TIMESTAMPING SO_TIMESTAMPING_OLD > > + > > +#define SO_RCVTIMEO SO_RCVTIMEO_OLD > > +#define SO_SNDTIMEO SO_SNDTIMEO_OLD > > Maybe I'm a bit late in this discussion as you are already in v5 ... > > I can see patches making the transition in different steps where it > might be helpful to name them *_OLD and *_NEW to understand the patches. > > But in the end the naming stays in the kernel for a very long time and I > remember myself (in early years) to name things 'new', 'new2', 'new3'. > > In fact SO_TIMESTAMP_OLD should be named SO_TIMESTAMP32 and > SO_TIMESTAMP_NEW should be named SO_TIMESTAMP64. Hmm. SO_TIMESTAMP_OLD uses 64-bit time_t on a 64 bit machine. In fact, there is no difference between the two options on a 64 bit machine. So using SO_TIMESTAMP_32 is just wrong. Likewise, SO_TIMESTAMP_64 naming somehow indicates that the existing one was not, and that is also not true on a 64-bit machine. Further, userspace will still continue to use SO_TIMESTAMP and the macros take care of which option to select internally. Moreover, these macros have been there for more than ten years (introduced before 2.4) and there has been no change. I doubt you will ever have NEW2. I think this argument is similar to saying don=E2=80=99t name these macros SO_TIMESTAMP because there might be SO_TIMESTAMP1 some day. There is never a perfect name. SO_TIMESTAMPING is also not really descriptive. > Especially as it tells you what is 'inside', the naming of these new intr= oduced constants should be replaced with *32 and *64 names. > The documentation and the other comments still fit perfectly then. I would prefer not to do this, for reasons mentioned above. Since you point out that it is easier to use this naming for intermediate steps, I suggest that we leave the series as it is. If you feel strongly to post a follow-on renaming patch, you could discuss it with the subsystem maintainers, if you think there is a correct but more descriptive naming. -Deepa > Regards, > Oliver From mboxrd@z Thu Jan 1 00:00:00 1970 From: Deepa Dinamani Date: Sat, 2 Feb 2019 18:47:20 -0800 Subject: [Cluster-devel] [PATCH net-next v5 12/12] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW In-Reply-To: <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> References: <20190202153454.7121-1-deepa.kernel@gmail.com> <20190202153454.7121-13-deepa.kernel@gmail.com> <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, Feb 2, 2019 at 9:15 AM Oliver Hartkopp wrote: > > Hi all, > > On 02.02.19 16:34, Deepa Dinamani wrote: > > Add new socket timeout options that are y2038 safe. > (..) > > > > diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h > > index 9826d1db71d0..0d0fddb7e738 100644 > > --- a/arch/alpha/include/uapi/asm/socket.h > > +++ b/arch/alpha/include/uapi/asm/socket.h > > @@ -119,19 +119,25 @@ > > #define SO_TIMESTAMPNS_NEW 64 > > #define SO_TIMESTAMPING_NEW 65 > > > > -#if !defined(__KERNEL__) > > +#define SO_RCVTIMEO_NEW 66 > > +#define SO_SNDTIMEO_NEW 67 > > > > -#define SO_RCVTIMEO SO_RCVTIMEO_OLD > > -#define SO_SNDTIMEO SO_SNDTIMEO_OLD > > +#if !defined(__KERNEL__) > > > > #if __BITS_PER_LONG == 64 > > #define SO_TIMESTAMP SO_TIMESTAMP_OLD > > #define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD > > #define SO_TIMESTAMPING SO_TIMESTAMPING_OLD > > + > > +#define SO_RCVTIMEO SO_RCVTIMEO_OLD > > +#define SO_SNDTIMEO SO_SNDTIMEO_OLD > > Maybe I'm a bit late in this discussion as you are already in v5 ... > > I can see patches making the transition in different steps where it > might be helpful to name them *_OLD and *_NEW to understand the patches. > > But in the end the naming stays in the kernel for a very long time and I > remember myself (in early years) to name things 'new', 'new2', 'new3'. > > In fact SO_TIMESTAMP_OLD should be named SO_TIMESTAMP32 and > SO_TIMESTAMP_NEW should be named SO_TIMESTAMP64. Hmm. SO_TIMESTAMP_OLD uses 64-bit time_t on a 64 bit machine. In fact, there is no difference between the two options on a 64 bit machine. So using SO_TIMESTAMP_32 is just wrong. Likewise, SO_TIMESTAMP_64 naming somehow indicates that the existing one was not, and that is also not true on a 64-bit machine. Further, userspace will still continue to use SO_TIMESTAMP and the macros take care of which option to select internally. Moreover, these macros have been there for more than ten years (introduced before 2.4) and there has been no change. I doubt you will ever have NEW2. I think this argument is similar to saying don?t name these macros SO_TIMESTAMP because there might be SO_TIMESTAMP1 some day. There is never a perfect name. SO_TIMESTAMPING is also not really descriptive. > Especially as it tells you what is 'inside', the naming of these new introduced constants should be replaced with *32 and *64 names. > The documentation and the other comments still fit perfectly then. I would prefer not to do this, for reasons mentioned above. Since you point out that it is easier to use this naming for intermediate steps, I suggest that we leave the series as it is. If you feel strongly to post a follow-on renaming patch, you could discuss it with the subsystem maintainers, if you think there is a correct but more descriptive naming. -Deepa > Regards, > Oliver From mboxrd@z Thu Jan 1 00:00:00 1970 From: Deepa Dinamani Subject: Re: [PATCH net-next v5 12/12] sock: Add SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW Date: Sat, 2 Feb 2019 18:47:20 -0800 Message-ID: References: <20190202153454.7121-1-deepa.kernel@gmail.com> <20190202153454.7121-13-deepa.kernel@gmail.com> <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> Mime-Version: 1.0 Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <0fad3f4d-4c0e-d9f2-1af0-7890d40c19c0@hartkopp.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: y2038-bounces@lists.linaro.org Sender: "Y2038" Content-Type: text/plain; charset="windows-1252" To: Oliver Hartkopp Cc: linux-arch , Parisc List , Arnd Bergmann , y2038 Mailman List , Linux Network Devel Mailing List , Helge Deller , Linux Kernel Mailing List , Ralf Baechle , linux-mips@vger.kernel.org, cluster-devel , ccaulfie@redhat.com, Paul Mackerras , linux-alpha@vger.kernel.org, sparclinux , linuxppc-dev , "David S. Miller" , Richard Henderson T24gU2F0LCBGZWIgMiwgMjAxOSBhdCA5OjE1IEFNIE9saXZlciBIYXJ0a29wcCA8c29ja2V0Y2Fu QGhhcnRrb3BwLm5ldD4gd3JvdGU6Cj4KPiBIaSBhbGwsCj4KPiBPbiAwMi4wMi4xOSAxNjozNCwg RGVlcGEgRGluYW1hbmkgd3JvdGU6Cj4gPiBBZGQgbmV3IHNvY2tldCB0aW1lb3V0IG9wdGlvbnMg dGhhdCBhcmUgeTIwMzggc2FmZS4KPiAoLi4pCj4gPgo+ID4gZGlmZiAtLWdpdCBhL2FyY2gvYWxw aGEvaW5jbHVkZS91YXBpL2FzbS9zb2NrZXQuaCBiL2FyY2gvYWxwaGEvaW5jbHVkZS91YXBpL2Fz bS9zb2NrZXQuaAo+ID4gaW5kZXggOTgyNmQxZGI3MWQwLi4wZDBmZGRiN2U3MzggMTAwNjQ0Cj4g PiAtLS0gYS9hcmNoL2FscGhhL2luY2x1ZGUvdWFwaS9hc20vc29ja2V0LmgKPiA+ICsrKyBiL2Fy Y2gvYWxwaGEvaW5jbHVkZS91YXBpL2FzbS9zb2NrZXQuaAo+ID4gQEAgLTExOSwxOSArMTE5LDI1 IEBACj4gPiAgICNkZWZpbmUgU09fVElNRVNUQU1QTlNfTkVXICAgICAgNjQKPiA+ICAgI2RlZmlu ZSBTT19USU1FU1RBTVBJTkdfTkVXICAgICA2NQo+ID4KPiA+IC0jaWYgIWRlZmluZWQoX19LRVJO RUxfXykKPiA+ICsjZGVmaW5lIFNPX1JDVlRJTUVPX05FVyAgICAgICAgIDY2Cj4gPiArI2RlZmlu ZSBTT19TTkRUSU1FT19ORVcgICAgICAgICA2Nwo+ID4KPiA+IC0jZGVmaW5lICAgICAgU09fUkNW VElNRU8gU09fUkNWVElNRU9fT0xECj4gPiAtI2RlZmluZSAgICAgIFNPX1NORFRJTUVPIFNPX1NO RFRJTUVPX09MRAo+ID4gKyNpZiAhZGVmaW5lZChfX0tFUk5FTF9fKQo+ID4KPiA+ICAgI2lmIF9f QklUU19QRVJfTE9ORyA9PSA2NAo+ID4gICAjZGVmaW5lIFNPX1RJTUVTVEFNUCAgICAgICAgICAg ICAgICBTT19USU1FU1RBTVBfT0xECj4gPiAgICNkZWZpbmUgU09fVElNRVNUQU1QTlMgICAgICAg ICAgICAgIFNPX1RJTUVTVEFNUE5TX09MRAo+ID4gICAjZGVmaW5lIFNPX1RJTUVTVEFNUElORyAg ICAgICAgIFNPX1RJTUVTVEFNUElOR19PTEQKPiA+ICsKPiA+ICsjZGVmaW5lIFNPX1JDVlRJTUVP ICAgICAgICAgIFNPX1JDVlRJTUVPX09MRAo+ID4gKyNkZWZpbmUgU09fU05EVElNRU8gICAgICAg ICAgU09fU05EVElNRU9fT0xECj4KPiBNYXliZSBJJ20gYSBiaXQgbGF0ZSBpbiB0aGlzIGRpc2N1 c3Npb24gYXMgeW91IGFyZSBhbHJlYWR5IGluIHY1IC4uLgo+Cj4gSSBjYW4gc2VlIHBhdGNoZXMg bWFraW5nIHRoZSB0cmFuc2l0aW9uIGluIGRpZmZlcmVudCBzdGVwcyB3aGVyZSBpdAo+IG1pZ2h0 IGJlIGhlbHBmdWwgdG8gbmFtZSB0aGVtICpfT0xEIGFuZCAqX05FVyB0byB1bmRlcnN0YW5kIHRo ZSBwYXRjaGVzLgo+Cj4gQnV0IGluIHRoZSBlbmQgdGhlIG5hbWluZyBzdGF5cyBpbiB0aGUga2Vy bmVsIGZvciBhIHZlcnkgbG9uZyB0aW1lIGFuZCBJCj4gcmVtZW1iZXIgbXlzZWxmIChpbiBlYXJs eSB5ZWFycykgdG8gbmFtZSB0aGluZ3MgJ25ldycsICduZXcyJywgJ25ldzMnLgo+Cj4gSW4gZmFj dCBTT19USU1FU1RBTVBfT0xEIHNob3VsZCBiZSBuYW1lZCBTT19USU1FU1RBTVAzMiBhbmQKPiBT T19USU1FU1RBTVBfTkVXIHNob3VsZCBiZSBuYW1lZCBTT19USU1FU1RBTVA2NC4KCkhtbS4gU09f VElNRVNUQU1QX09MRCB1c2VzIDY0LWJpdCB0aW1lX3Qgb24gYSA2NCBiaXQgbWFjaGluZS4gSW4g ZmFjdCwKdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gb3B0aW9ucyBvbiBh IDY0IGJpdCBtYWNoaW5lLiBTbwp1c2luZyAgU09fVElNRVNUQU1QXzMyIGlzIGp1c3Qgd3Jvbmcu CgpMaWtld2lzZSwgU09fVElNRVNUQU1QXzY0IG5hbWluZyBzb21laG93IGluZGljYXRlcyB0aGF0 IHRoZSBleGlzdGluZwpvbmUgd2FzIG5vdCwgYW5kIHRoYXQgaXMgYWxzbyBub3QgdHJ1ZSBvbiBh IDY0LWJpdCBtYWNoaW5lLgoKRnVydGhlciwgdXNlcnNwYWNlIHdpbGwgc3RpbGwgY29udGludWUg dG8gdXNlIFNPX1RJTUVTVEFNUCBhbmQgdGhlCm1hY3JvcyB0YWtlIGNhcmUgb2Ygd2hpY2ggb3B0 aW9uIHRvIHNlbGVjdCBpbnRlcm5hbGx5LgoKTW9yZW92ZXIsIHRoZXNlIG1hY3JvcyBoYXZlIGJl ZW4gdGhlcmUgZm9yIG1vcmUgdGhhbiB0ZW4geWVhcnMKKGludHJvZHVjZWQgYmVmb3JlIDIuNCkg YW5kIHRoZXJlIGhhcyBiZWVuIG5vIGNoYW5nZS4gSSBkb3VidCB5b3Ugd2lsbApldmVyIGhhdmUg TkVXMi4KSSB0aGluayB0aGlzIGFyZ3VtZW50IGlzIHNpbWlsYXIgdG8gc2F5aW5nIGRvbuKAmXQg bmFtZSB0aGVzZSBtYWNyb3MKU09fVElNRVNUQU1QIGJlY2F1c2UgdGhlcmUgbWlnaHQgYmUgU09f VElNRVNUQU1QMSBzb21lIGRheS4gVGhlcmUgaXMKbmV2ZXIgYSBwZXJmZWN0IG5hbWUuIFNPX1RJ TUVTVEFNUElORyBpcyBhbHNvIG5vdCByZWFsbHkgZGVzY3JpcHRpdmUuCgo+IEVzcGVjaWFsbHkg YXMgaXQgdGVsbHMgeW91IHdoYXQgaXMgJ2luc2lkZScsIHRoZSBuYW1pbmcgb2YgdGhlc2UgbmV3 IGludHJvZHVjZWQgY29uc3RhbnRzIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoICozMiBhbmQgKjY0 IG5hbWVzLgo+IFRoZSBkb2N1bWVudGF0aW9uIGFuZCB0aGUgb3RoZXIgY29tbWVudHMgc3RpbGwg Zml0IHBlcmZlY3RseSB0aGVuLgoKSSB3b3VsZCBwcmVmZXIgbm90IHRvIGRvIHRoaXMsIGZvciBy ZWFzb25zIG1lbnRpb25lZCBhYm92ZS4gU2luY2UgeW91CnBvaW50IG91dCB0aGF0IGl0IGlzIGVh c2llciB0byB1c2UgdGhpcyBuYW1pbmcgZm9yIGludGVybWVkaWF0ZSBzdGVwcywKSSBzdWdnZXN0 IHRoYXQgd2UgbGVhdmUgdGhlIHNlcmllcyBhcyBpdCBpcy4KSWYgeW91IGZlZWwgc3Ryb25nbHkg dG8gcG9zdCBhIGZvbGxvdy1vbiByZW5hbWluZyBwYXRjaCwgeW91IGNvdWxkCmRpc2N1c3MgaXQg d2l0aCB0aGUgc3Vic3lzdGVtIG1haW50YWluZXJzLCBpZiB5b3UgdGhpbmsgdGhlcmUgaXMgYQpj b3JyZWN0IGJ1dCBtb3JlIGRlc2NyaXB0aXZlIG5hbWluZy4KCi1EZWVwYQoKPiBSZWdhcmRzLAo+ IE9saXZlcgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpZ MjAzOCBtYWlsaW5nIGxpc3QKWTIwMzhAbGlzdHMubGluYXJvLm9yZwpodHRwczovL2xpc3RzLmxp bmFyby5vcmcvbWFpbG1hbi9saXN0aW5mby95MjAzOAo=