From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28630 invoked from network); 3 Dec 2023 06:02:30 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 3 Dec 2023 06:02:30 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 1C6EF416E1; Sun, 3 Dec 2023 16:02:20 +1000 (AEST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by minnie.tuhs.org (Postfix) with ESMTPS id 1655D40242 for ; Sun, 3 Dec 2023 16:02:09 +1000 (AEST) Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2c9f559b82cso6615261fa.0 for ; Sat, 02 Dec 2023 22:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701583327; x=1702188127; darn=tuhs.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=HnAI4NRx0hquyUW2ORgfZeo5y+OyY+fBaC5W1pYOAbQ=; b=b5014gDxhi8twfZmDXsgo1Zt1xol1zUjDmQpXcXX0TbIhcS772TuSuyJl1iWWthnYZ gMj4yMkF2oGNjLQrzLuUolmH33+c3cSCkfR9KXW4AU6QNDi02/7vivD3SztltRVBuPTp QylQmPU/Yz1QKW0R+DxnueFqT/TYCuD13f2VlOM9wh9R+JOiz/WK2aP+nGs6c8QSaxmf VdNmb4dSFagAbdO5OIEgUlJPgFu9nYYYWh3KH/vIJdbtE3CE01PnlZ1CLdaQBBOiTqF2 lW0h4iqXy4hdEsl8ag3zzMk82/uFxIjZCLSRnEMiRC6Tj+8RhenbU1an3eQXRtxA6u2T ErKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701583327; x=1702188127; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=HnAI4NRx0hquyUW2ORgfZeo5y+OyY+fBaC5W1pYOAbQ=; b=okgbx/yPGuK9LPTh3DI2OJEIxGgmdmw954tLSTKgWtW2SJztx2393UzwZGM2eoVZ5Y ismFQVliNQZfbs5AS+Y9X1tOoZIqV9Dan6zA4p/kalEN6mW9ftzd0UTuBCtk9uYVl549 vFwoYq3eK0z7d2vr0rvsJWkNWzPw90G0kLQEaFf71Yv4c/F/lRS9vhceBXD4RaX7s1fy dImJddg6/bJwWVirp+e0A5PjQwVweUcl1OjC7c3jzVt3jTaaf/BB1VS75f42aoqugU1D TCl5NQO/Fc/LGOlOPCPJMc6zsmK1w+HWXU6FxE7gxAFSBdsPz0uagPqNDOiui9uGFo+8 oYig== X-Gm-Message-State: AOJu0YwAvLTH3TzhFmZKF4LvKMvqxsaDTdaxjMdgGOMN5oh132YuPe5T ZPjPIs3frq9jqJ2PYRc3PSstezcMddCXvS3SR/KuwjsD X-Google-Smtp-Source: AGHT+IE1HyIyh7FGrsOCkbkF2n9XbuC9tXzYNSSJZKwJPiI99lRx39AkFog2a4V4wydxMNf8EeqgqC/mAET50YOY2S0= X-Received: by 2002:a2e:b04e:0:b0:2c9:f427:9e51 with SMTP id d14-20020a2eb04e000000b002c9f4279e51mr547012ljl.90.1701583326158; Sat, 02 Dec 2023 22:02:06 -0800 (PST) MIME-Version: 1.0 From: ron minnich Date: Sat, 2 Dec 2023 22:01:54 -0800 Message-ID: To: The Eunuchs Hysterical Society Content-Type: multipart/alternative; boundary="000000000000b62393060b94bdd8" Message-ID-Hash: KULDV4S7DDBOALYREAUYHHQUZKY3CZWX X-Message-ID-Hash: KULDV4S7DDBOALYREAUYHHQUZKY3CZWX X-MailFrom: rminnich@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] XID register List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000b62393060b94bdd8 Content-Type: text/plain; charset="UTF-8" SunRPC, among other protocols, needs transaction IDs (XIDs) to distinguish RPCs.For SunRPC, it's important that XIDs not be reused (not for all protocols; 9p has no such requirement). Stateless protocols like NFS and reused XIDs can get messy. There is a vague, 30 year old memory, I have, that at some point SPARC got a time register, or some other register, that always provided a different answer each time it was read, even if read back to back, in part to enable creation of non-reused XIDs. Note that things like the TSC or RISC-V MTIME register make no such guarantee. I am pretty sure someone here can fill me in, or tell me I'm wrong, about my SPARC memory. thanks --000000000000b62393060b94bdd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SunRPC, among other protocols, needs transaction IDs (XIDs= ) to distinguish RPCs.For SunRPC, it's important that XIDs not be reuse= d (not for all protocols; 9p has no such requirement). Stateless protocols = like NFS and reused XIDs can get messy.

There is a vague= , 30 year old memory, I have, that at some point SPARC got a time register,= or some other register, that always provided a different answer each time = it was read, even if read back to back, in part to enable creation=C2=A0of = non-reused XIDs. Note that things like the TSC or RISC-V MTIME register mak= e no such guarantee.

I am pretty sure someone here= can fill me in, or tell me I'm wrong, about my SPARC memory.

thanks
--000000000000b62393060b94bdd8--