OK, turing.

<- leave blank

Sun May 22 22:54:33 EDT 2022

<a href=https://lead-market.ru>lead-market.ru</a>


Sun May 22 16:46:07 EDT 2022
ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=pass (2048-bit rsa
key
 sha256) header.d=gmail.com header.i=@gmail.com header.b=DAqk099R
 header.a=rsa-sha256 header.s=20210112 x-bits=2048; dmarc=pass
 policy.published-domain-policy=none
 policy.published-subdomain-policy=quarantine policy.applied-disposition=none
 policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none)
 policy.policy-from=p header.from=gmail.com; spf=pass
 smtp.mailfrom=crossd@gmail.com smtp.helo=mail-oa1-f50.google.com;
 x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message
 has been altered)) (Message modified while forwarding at Topicbox)
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
	topicbox.com; h=mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type:list-help:list-id:list-post
	:list-subscribe:reply-to:content-transfer-encoding
	:list-unsubscribe; s=sysmsg-1; t=1653251741; bh=lq5f6BuiCJVwbmjo
	aLpeqPf01W8BWv5DiEcq40j71JY=; b=ATJJBjcQLHmBHX46mMrnCsXX7XvnLqoh
	ChgemX8zDvoDAjogZtQVXmfAKXDfAtnIm7tH0OTmhimB7Kl5Tg3ME7llWxRqPSFR
	zgyEB37hHg9+diQKOkGPVVRyslkivT4q/ZeMXwsMXtZYsU+ARSIUl0F7vChQd3H+
	raSxCYai13g=
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t=
	1653251741; b=pl1gPOg3JTwNGhW9RVBMWRe4n0wIireV380CcT9aiFxW/ty9xq
	d6DE5k7T+TrjARPciOswK163eMsZvSpnVnFStXMRw5+xycm854USsT+YLRI0nf8H
	/o3hxWkoUwn7Z9BPyywT1pwQR/gEo2Uu1qw2Suzu+Tsa0YnrptM2w7Jfg=
Authentication-Results: topicbox.com; arc=pass; dkim=pass (2048-bit rsa key
 sha256) header.d=gmail.com header.i=@gmail.com header.b=DAqk099R
 header.a=rsa-sha256 header.s=20210112 x-bits=2048; dmarc=pass
 policy.published-domain-policy=none
 policy.published-subdomain-policy=quarantine policy.applied-disposition=none
 policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none)
 policy.policy-from=p header.from=gmail.com; spf=pass
 smtp.mailfrom=crossd@gmail.com smtp.helo=mail-oa1-f50.google.com;
 x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message
 has been altered)) (Message modified while forwarding at Topicbox)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t=
    1653251608; b=Jklcw0e/I9p3DsDgGTUcjdsl79AhCJnPeC9AKQxOrBVngdU0UX
    L9SkguCyhNTibfekDLEZN9RT3HNDUrFvLK3/3Rz1Q6x66KwQrEEl6s0cFRffhBJQ
    SL5IKoNgN5Gu3NQDjVV2zyt0oyNPtYDk0NINHzHWAld+Y8rFDQDQFaMt3OonT5MH
    eYZr/L3vTTK8PnyTUJZ+x7+A7mJy+FFlnMMI6kufm0pvBtXM41cDLtbTSWCLVe49
    QIc8OcwYKpnq//fY86aBMAk1/IdaNBAjJPOJNL0NCKDCj/E+h1m0V3DQwdjcuXzD
    wj6G94KYyQr7cGoJjRbtrlwqqdU54Z3+60Gw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
    topicbox.com; h=mime-version:references:in-reply-to:from:date
    :message-id:subject:to:content-type; s=arcseal; t=1653251608;
    bh=aFf+bZdyCxhUiAa43UInD+PPGwUXtLLlLzyC8rDBSXI=; b=gD8xLmPtGws5
    C4KFgHRUGhr0rlmYKX6eZ9Golq1qKOE8LJarKizD48bwkVp0PKqrj1aFbCf7NbC0
    FltZOEUjCzcA9i/d5ZAw1AG4ChU6Hn1NaAmv3XMpT604kX9sGd0Yi8vvB/BeQZqa
    +nabKoAt459U6urHx24y15J0akKwsY45gK6ykdAzfyUtb6zLQGrw6caHhANfQEXX
    nIfmOoybXHc7GFA6ggf/2cudJeldfEVwkRwXHjxdNeL6oFVhEGkXtZ1StyxiaWU9
    ABO7OK3msVFWJsHKeUhCiWDfbLxTv1b1yDlCjlTegOuCD5XrGivrH3WdQwEfvzrw
    jfVcZAdTJg==
ARC-Authentication-Results: i=1; tb-mx0.topicbox.com;
    arc=none (no signatures found);
    bimi=skipped (DMARC Policy is not at enforcement);
    dkim=pass (2048-bit rsa key sha256) header.d=gmail.com
    header.i=@gmail.com header.b=DAqk099R header.a=rsa-sha256
    header.s=20210112 x-bits=2048;
    dmarc=pass policy.published-domain-policy=none
    policy.published-subdomain-policy=quarantine
    policy.applied-disposition=none policy.evaluated-disposition=none
    (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p
    header.from=gmail.com;
    iprev=pass smtp.remote-ip=209.85.160.50 (mail-oa1-f50.google.com);
    spf=pass smtp.mailfrom=crossd@gmail.com
    smtp.helo=mail-oa1-f50.google.com;
    x-aligned-from=pass (Address match);
    x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net
    header.i=@1e100.net header.b=CDt2UGgz;
    x-me-sender=none;
    x-ptr=pass smtp.helo=mail-oa1-f50.google.com
    policy.ptr=mail-oa1-f50.google.com;
    x-return-mx=pass header.domain=gmail.com policy.is_org=yes
    (MX Records found:
    alt1.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com);
    x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes
    (MX Records found:
    alt1.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com);
    x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384
    smtp.bits=256/256;
    x-vs=clean score=0 state=0
Received-SPF: pass
    (gmail.com ...  _spf.google.com: Sender is authorized to use
    'crossd@gmail.com' in 'mfrom' identity (mechanism
    'include:_netblocks.google.com' matched))
    receiver=tb-mx0.topicbox.com;
    identity=mailfrom;
    envelope-from="crossd@gmail.com";
    helo=mail-oa1-f50.google.com;
    client-ip=209.85.160.50
From: Dan Cross <crossd@gmail.com>
Date: Sun, 22 May 2022 16:33:14 -0400
Subject: Re: [9fans] Aarch64 on labs|9legacy?
To: 9fans <9fans@9fans.net>
Topicbox-Policy-Reasoning: allow: sender is a member
Topicbox-Message-UUID: 7299f3e2-da0e-11ec-975f-b9a3b4f6b4e9
Archived-At:
<https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M29e6e0dfdc06aad0e373cbbd>
Reply-To: 9fans <9fans@9fans.net>
Topicbox-Delivery-ID:
 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:9e00e022-a139-11eb-b835-09bb272d11b0:M29e6e0dfdc06aad0e373cbbd:1:qNjvNsbATbQdeVm7QH9FyAdn49Il9yRm7pBQpdEjToE

On Sun, May 22, 2022, 4:16 PM adr <adr@sdf.org> wrote:

> Has someone done something with aarch64 on labs|9legacy?
> It's called arm64
>
> Great.
>
> Because with this 4 magical words I was supposed to find...  what?
> Where?  What are you talking about?  Where is this work on Bell Labs'
> plan9 that I could find using the string "arm64" (which of course
> I knew already from 9front, the only distribution with aarch64
> support)?  Even in Inferno there is no aarch64 support.  Where are
> this people publishing aarch64 work in the labs distribution that
> I could fing using "arm64"?  What are you talking about?
>
> But now after all the useful interesting contribution to the list,
> as usual, you have time to even express sarcasm.
>
> You haven't help me to find anything, you don't have to do it, of
> course, but then don't talk like you have done it.
>

I've known and observed Charles for a very long time, indeed.  I can imagine
how you interpreted what he wrote as you have, but perhaps consider that he
didn't mean what he wrote in the way you have taken it.

A simple question, a fucking simple question and here we go with
> the trolling and the bullshit, I'm done with this fucking list.
>

Probably for the best.

	- Dan C.

------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M29e6e0dfdc06aad0e373cbbd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription




Sun May 22 16:22:31 EDT 2022
From: "Theo de Raadt" <deraadt@openbsd.org>
To: Caspar Schutijser <caspar@schutijser.com>,
    Landry Breuil <landry@openbsd.org>, ports@openbsd.org
Mail-Followup-To: Caspar Schutijser <caspar@schutijser.com>,
		  Landry Breuil <landry@openbsd.org>, ports@openbsd.org
Subject: Re: firefox: pledge violation through pkcs11/smart card usage
Comments: In-reply-to Stuart Henderson <stu@spacehopper.org>
   message dated "Sun, 22 May 2022 18:44:51 +0100."
Date: Sun, 22 May 2022 11:54:42 -0600
Sender: owner-ports@openbsd.org

Stuart Henderson <stu@spacehopper.org> wrote:

> On 2022/05/22 08:58, Theo de Raadt wrote:
> > The existing code uses mlock.  It appears to be using mlock for a
> > privacy reason.  But mlock has no privacy reason.
> > The mlock page does not make any privacy or security promises at all.
>
> OpenSC is used on Linux too, mlock there does give some guarantees:
>
> mlock(), mlock2(), and mlockall() lock part or all of the calling
> process's virtual address space into RAM, preventing that memory
> from being paged to the swap area.
>
> ...
>
> Memory locking has two main applications: real-time algorithms
> and high-security data processing.  Real-time applications
> require deterministic timing, and, like scheduling, paging is one
> major cause of unexpected program execution delays.  Real-time
> applications will usually also switch to a real-time scheduler
> with sched_setscheduler(2).  Cryptographic security software
> often handles critical bytes like passwords or secret keys as
> data structures.  As a result of paging, these secrets could be
> transferred onto a persistent swap store medium, where they might
> be accessible to the enemy long after the security software has
> erased the secrets in RAM and terminated.  (But be aware that the
> suspend mode on laptops and some desktop computers will save a
> copy of the system's RAM to disk, regardless of memory locks.)

POSIX has this to say on the matter:

https://pubs.opengroup.org/onlinepubs/009696699/functions/mlock.html

None of what Linux is doing here is in the spec, and I would argue it isn't
even in the spirit of what mlock was for ("performance").

So maybe just #ifdef __linux__ that block, and submit back to upstream.
I really think replacing this with calloc_conceal(3) is junk science.

> > This library is used in a gigantic program which does a ton of other
> > memory allocations, which uses a huge number of other libraries which
> > do a ton of other memory allocations.

Is it used in libcrypto?  No.

> It's used in smaller programs too.  Like OpenSSH.

openssh does not use mlock.

We really never know when a 'secret' is going to be put into memory,
because noone built for that model of strict object handling.  And
since openssh to a large degree uses libcrypto, it means there are
'un-mlocked secrets there also'.  Even the bignum library used by
asn1 doesn't do this.  In some classes of software, it is keys at the
bottom, and secrets above.  It is junk science to secrecy-lock the
keys without secrecy-locking the user's data, as the purpose of the
keys is to provide a variety of security gaurantees to the various
kinds of data.

For this library, used in this application, to suddenly want this
requirement fulfilled in such a narrow scope, is completely pointless.

Maybe malloc -- and mmap for that matter -- should mlock all memory,
just in case the user of that memory should be better protected than
careful process memory management?

In an abundance of caution of course, why show any concern for the
downsides and consequences.

/sarcasm.





Sun May 22 16:22:17 EDT 2022
From: "Theo de Raadt" <deraadt@openbsd.org>
To: Caspar Schutijser <caspar@schutijser.com>,
    Landry Breuil <landry@openbsd.org>, ports@openbsd.org
Mail-Followup-To: Caspar Schutijser <caspar@schutijser.com>,
		  Landry Breuil <landry@openbsd.org>, ports@openbsd.org
Subject: Re: firefox: pledge violation through pkcs11/smart card usage
Comments: In-reply-to Stuart Henderson <stu@spacehopper.org>
   message dated "Sun, 22 May 2022 13:15:03 +0100."
Date: Sun, 22 May 2022 08:58:36 -0600
Sender: owner-ports@openbsd.org

Stuart Henderson <stu@spacehopper.org> wrote:

> On 2022/05/22 13:49, Caspar Schutijser wrote:
> > I haven't tested this but shouldn't this be HAVE_CALLOC_CONCEAL?

I really don't understand the approach being taken here.

The existing code uses mlock.  It appears to be using mlock for a
privacy reason.  But mlock has no privacy reason.

The mlock page does not make any privacy or security promises at all.
At best it says "This region will be available in direct memory, without
having to retrieve it from some (vague) slower memory" It does not say
that a copy of this allocation won't go to swap.  It also does not say
that the contents won't land in coredump.  mlock is a weird performance
gaurantee system call which noone should actually use (and I want to
remove) because it locks resources other processes might require.

mlock is apparently being used for a reason that isn't specified or
documented.

But I want to understand what the goal here is.

A subset of memory allocations in one library is being treated this way,
for "secrecy" or "privacy".

This library is used in a gigantic program which does a ton of other
memory allocations, which uses a huge number of other libraries which
do a ton of other memory allocations.

Does that gigantic program keep track of any other secrets or privacy
information in the other memory allocations it makes?

Once this diff for this one library goes in, will that huge program
and all the libraries it use receive the same attention?  I would estimate
it will require 10,000+ commits to the whole tree -- base and ports -- if
we wanted to actually solve this problem.

It won't happen.

Unfortunately, our calloc_conceal() is in the same boat.  Using it in a few
corners of the tree ...  feels so ineffective.





Sun May 22 16:19:18 EDT 2022
ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=none (no signatures
 found); dmarc=pass policy.published-domain-policy=none
 policy.published-subdomain-policy=none policy.applied-disposition=none
 policy.evaluated-disposition=none (p=none,sp=none,d=none,d.eval=none)
 policy.policy-from=p header.from=sdf.org; spf=pass smtp.mailfrom=adr@SDF.ORG
 smtp.helo=mx.sdf.org; x-internal-arc=fail (as.1.topicbox.com=pass,
 ams.1.topicbox.com=fail (message has been altered)) (Message modified while
 forwarding at Topicbox)
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
	topicbox.com; h=date:from:to:subject:in-reply-to:message-id
	:references:mime-version:content-type:list-help:list-id
	:list-post:list-subscribe:reply-to:content-transfer-encoding
	:list-unsubscribe; s=sysmsg-1; t=1653250630; bh=+J1m5FhzWb1j6Bdj
	cKn97CdvjuySr+J9n+Sl0RbRglM=; b=ZvaxWayAgRhNy/oyIhNp0SCdIjU2/agN
	2HNkk3C/A9yt6lxnpi/tTlUzpaXDmSa25nxkNrD5+PtJYNVuWlWzyoMxYPcvtmF7
	latPW5WpDJJk2VcuxzvApz2Vrv3cmKH6brB2GuvNWBFq49sd2f0xpR+s8jMx0hv/
	zYTPFbsgQk8=
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t=
	1653250630; b=V9J0TArMaIcsM6TcAppAWSHcAZgyOLhLzZpO7RfSHhlIVOLwAz
	NvkoJLw5kwDcAsmbvsl4HGk6uN7p1YkC6hAR1EsIiBVZG6lw/vt7pkYS6+CgFLrF
	HNBITIRynnTCeQs0flLP6uSQcuMdlpBXhmd4jddzk3r2NbvTIDfPDCios=
Authentication-Results: topicbox.com; arc=pass; dkim=none (no signatures
 found); dmarc=pass policy.published-domain-policy=none
 policy.published-subdomain-policy=none policy.applied-disposition=none
 policy.evaluated-disposition=none (p=none,sp=none,d=none,d.eval=none)
 policy.policy-from=p header.from=sdf.org; spf=pass smtp.mailfrom=adr@SDF.ORG
 smtp.helo=mx.sdf.org; x-internal-arc=fail (as.1.topicbox.com=pass,
 ams.1.topicbox.com=fail (message has been altered)) (Message modified while
 forwarding at Topicbox)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t=
    1653250509; b=VrqkscdOfF0ErQIyUPz85dffvQ5dbnrvDbrblucqbE7oVJQfgQ
    YAZ95LdD01KoIi+2ioXmc9vhTTIvulPfqvdQuzBuwJ1z6/JCfewU3gW2cBu/EThz
    vUKKzIEfLkXFtHCYarWhwEbggU1iRivge2kBq7zUdbcXFct5WmB77vq7fryYe5lP
    eCuWzEYLEul1OqkQnSuJ3VYYLsI3lWoV3i9JVgiDHU0RU7UFFAVYsQOmQqetmp3Q
    BorP0Y6kf9/NyggtUoO6XhdenjdGqZRPQZbkB3+l4m7tVPasJKeE8hKAGyrRvWv9
    HM49krTWeujoH62RiAIElRzIhOY2u8+5uLRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
    topicbox.com; h=date:from:to:subject:in-reply-to:message-id
    :references:mime-version:content-type; s=arcseal; t=1653250509;
    bh=/N967Xt7/WAhc/w7RFS1OtkgChm5/m5s20BnZuSm+e0=; b=rFVynLGSI7/H
    0Ex9UnMAjIzMYqA/YgW9gKD48SUdUoMzd/akBENqafD7XQIu2+/X0dV0qrGLcQ/a
    dAl84TxwUYud6kOTYfBUohYo0NVe6FyvBjKPsPuMA0ivkb7lB1FOXIXM5P2wH9on
    xHo8qzPRsunEzUh4/NuPmVM8l6Zu9zXJH9EGo109E/53qZVB73+w7k4XGWBqxrBh
    ItUpehXkk73xGExlgAFhv9ELEw0REnIZIMPM6yi8j8JxwHbwmB33mUfEHZ0S+nbJ
    HgmgKIEfyX08aZs9tHMm8kghk1LMihQam7AnOasdtLBvBbtZJLOvp9lC9gyhKO1s
    iGOhSQDKtA==
ARC-Authentication-Results: i=1; tb-mx0.topicbox.com;
    arc=none (no signatures found);
    bimi=skipped (DMARC Policy is not at enforcement);
    dkim=none (no signatures found);
    dmarc=pass policy.published-domain-policy=none
    policy.published-subdomain-policy=none policy.applied-disposition=none
    policy.evaluated-disposition=none (p=none,sp=none,d=none,d.eval=none)
    policy.policy-from=p header.from=sdf.org;
    iprev=pass smtp.remote-ip=205.166.94.24 (mx.sdf.org);
    spf=pass smtp.mailfrom=adr@SDF.ORG smtp.helo=mx.sdf.org;
    x-aligned-from=pass (Address match);
    x-me-sender=none;
    x-ptr=pass smtp.helo=mx.sdf.org policy.ptr=mx.sdf.org;
    x-return-mx=pass header.domain=sdf.org policy.is_org=yes
    (MX Records found: mx.sdf.org);
    x-return-mx=pass smtp.domain=sdf.org policy.is_org=yes
    (MX Records found: mx.sdf.org);
    x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384
    smtp.bits=256/256;
    x-vs=clean score=0 state=0
Received-SPF: pass
    (sdf.org: 205.166.94.24 is authorized to use 'adr@SDF.ORG' in 'mfrom' identity
    (mechanism 'ip4:205.166.94.0/24' matched))
    receiver=tb-mx0.topicbox.com;
    identity=mailfrom;
    envelope-from="adr@SDF.ORG";
    helo=mx.sdf.org;
    client-ip=205.166.94.24
Date: Sun, 22 May 2022 20:15:06 +0000 (UTC)
From: adr <adr@SDF.ORG>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] Aarch64 on labs|9legacy?
Topicbox-Policy-Reasoning: allow: sender is a member
Topicbox-Message-UUID: e46eee80-da0b-11ec-adcf-c9b62682de61
Archived-At:
<https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M811670166425640dec9b3703>
Reply-To: 9fans <9fans@9fans.net>
Topicbox-Delivery-ID:
 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:9e00e022-a139-11eb-b835-09bb272d11b0:M811670166425640dec9b3703:1:Z4keuj3Sp3SAP07yDiLSTalq3Zf3aK7I2o7HS1DTNX4

Has someone done something with aarch64 on labs|9legacy?
It's called arm64

Great.

Because with this 4 magical words I was supposed to find...  what?
Where?  What are you talking about?  Where is this work on Bell Labs'
plan9 that I could find using the string "arm64" (which of course
I knew already from 9front, the only distribution with aarch64
support)?  Even in Inferno there is no aarch64 support.  Where are
this people publishing aarch64 work in the labs distribution that
I could fing using "arm64"?  What are you talking about?

But now after all the useful interesting contribution to the list,
as usual, you have time to even express sarcasm.

You haven't help me to find anything, you don't have to do it, of
course, but then don't talk like you have done it.

A simple question, a fucking simple question and here we go with
the trolling and the bullshit, I'm done with this fucking list.

------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M811670166425640dec9b3703
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription




Sun May 22 16:19:07 EDT 2022
ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=pass (2048-bit rsa
key
 sha256) header.d=gmail.com header.i=@gmail.com header.b=k4xda904
 header.a=rsa-sha256 header.s=20210112 x-bits=2048; dmarc=pass
 policy.published-domain-policy=none
 policy.published-subdomain-policy=quarantine policy.applied-disposition=none
 policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none)
 policy.policy-from=p header.from=gmail.com; spf=pass
 smtp.mailfrom=charles.forsyth@gmail.com smtp.helo=mail-ed1-f47.google.com;
 x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message
 has been altered)) (Message modified while forwarding at Topicbox)
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
	topicbox.com; h=mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type:list-help:list-id:list-post
	:list-subscribe:reply-to:content-transfer-encoding
	:list-unsubscribe; s=sysmsg-1; t=1653243653; bh=3v8WJ/52DweyF9NL
	ZFQm5YbqIYQsmjcPRrONpSmTe+8=; b=E83iJnTrceRiVhDfzwDdgv52LRiNWlfL
	Sfd+p3EmW+ug/0YqZvxmWYwPhLMVPnHUkk7OEIecHcB3ta8b3uUho82Mga+pjmUr
	DSX210nTkiN71RAK0pt4mbSIhhZuBuO5IX8eURPx9DjWqln7810+YbvN64ZrFw2c
	cZLot1LK4gE=
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t=
	1653243653; b=l/ozyn3qeutMUa74OLnpAoUuzYvgeQ+4exOCuQUWXylLvVIPJn
	VIiitC2K0BRgYJOYMIUQhe5/XEcDstTScvzO7ueuNFzpCrP0iiQkYaCNbtwMKmLG
	JGGTVeIc0Ew0M9SbmG93/EWvZnt6O3SgC7fiLEqA4ieGph1RkGJp9Afwk=
Authentication-Results: topicbox.com; arc=pass; dkim=pass (2048-bit rsa key
 sha256) header.d=gmail.com header.i=@gmail.com header.b=k4xda904
 header.a=rsa-sha256 header.s=20210112 x-bits=2048; dmarc=pass
 policy.published-domain-policy=none
 policy.published-subdomain-policy=quarantine policy.applied-disposition=none
 policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none)
 policy.policy-from=p header.from=gmail.com; spf=pass
 smtp.mailfrom=charles.forsyth@gmail.com smtp.helo=mail-ed1-f47.google.com;
 x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message
 has been altered)) (Message modified while forwarding at Topicbox)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t=
    1653243526; b=E1H6DgoO3d07RN1sudWazT2X3mABsaW1kS7zIoeGOaKMwJBm6k
    H42tNeqa4cwo85BOnX1Kujp7WzVVhuVvVsoCPQ3VIVDe6JNksv8AR9WOLm9njSBr
    urE0X7I5AFlpMWUfME+vmfIearmLR4W3yhKIHCE55sbU+1F198cJJ3QIAdJgmz1b
    IOxYNOqEvoDSCbiUoAzeTpIPSfFQA/acNX91/FEODF0dwomMz3ITyp3RMAo5ZqUB
    DqPy5WpHechW2TstJnVmmuvAmSEQdNs6kKkN1bSDx6p6t/WrgDOPnir4ZU7T8o/6
    igsrZfYq8p+wtYKV36eqUpbiSKmvCPLyVu9A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
    topicbox.com; h=mime-version:references:in-reply-to:from:date
    :message-id:subject:to:content-type; s=arcseal; t=1653243526;
    bh=UCknuexKPA0ws0Hm6m4VHYnfP70T96m+ZcqoMf+avd8=; b=JE7gZ5B0Qq9H
    1JIEO3qZYL1ZsYJUl8OgLTGzEyo2vwrfxkmECMnaLiZeM6edRqU8z4NcQ2hXWeqU
    OmpffXNVDux9jpv/NHkK8rwyGD7EgGVtg9UXlpf36E4UPOB/iZ4PAmHB5Gnsz+cl
    GGP4bx2JiEeME9YwqiRPe4n/ri1+zuXoDrTq9PZIpfGgL+iiipYtgSw1TJYtXLLK
    e3MgMUF6LL9eSCOmLP6flCN4QQ6RsRIwMpqRN+GMrdq6I0RlWv7wU2X9+DtOYK5B
    UWPstPv+l0aNwTqdoJxSpujpaeDQW/N/t06zmanuv7G4GvZ91gm2FHhcYy1ixkWT
    P1NM8y4vsw==
ARC-Authentication-Results: i=1; tb-mx0.topicbox.com;
    arc=none (no signatures found);
    bimi=skipped (DMARC Policy is not at enforcement);
    dkim=pass (2048-bit rsa key sha256) header.d=gmail.com
    header.i=@gmail.com header.b=k4xda904 header.a=rsa-sha256
    header.s=20210112 x-bits=2048;
    dmarc=pass policy.published-domain-policy=none
    policy.published-subdomain-policy=quarantine
    policy.applied-disposition=none policy.evaluated-disposition=none
    (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p
    header.from=gmail.com;
    iprev=pass smtp.remote-ip=209.85.208.47 (mail-ed1-f47.google.com);
    spf=pass smtp.mailfrom=charles.forsyth@gmail.com
    smtp.helo=mail-ed1-f47.google.com;
    x-aligned-from=pass (Address match);
    x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net
    header.i=@1e100.net header.b=jleXFMdD;
    x-me-sender=none;
    x-ptr=pass smtp.helo=mail-ed1-f47.google.com
    policy.ptr=mail-ed1-f47.google.com;
    x-return-mx=pass header.domain=gmail.com policy.is_org=yes
    (MX Records found:
    alt4.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com);
    x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes
    (MX Records found:
    alt4.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com);
    x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384
    smtp.bits=256/256;
    x-vs=clean score=0 state=0
Received-SPF: pass
    (gmail.com ...  _spf.google.com: Sender is authorized to use
    'charles.forsyth@gmail.com' in 'mfrom' identity (mechanism
    'include:_netblocks.google.com' matched))
    receiver=tb-mx0.topicbox.com;
    identity=mailfrom;
    envelope-from="charles.forsyth@gmail.com";
    helo=mail-ed1-f47.google.com;
    client-ip=209.85.208.47
From: Charles Forsyth <charles.forsyth@gmail.com>
Date: Sun, 22 May 2022 19:18:34 +0100
Subject: Re: [9fans] Aarch64 on labs|9legacy?
To: 9fans <9fans@9fans.net>
Topicbox-Policy-Reasoning: allow: sender is a member
Topicbox-Message-UUID: a15cc8c0-d9fb-11ec-88fa-e2ec39de7134
Archived-At:
<https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M853e5a6fd4993355ec0b867f>
Reply-To: 9fans <9fans@9fans.net>
Topicbox-Delivery-ID:
 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:9e00e022-a139-11eb-b835-09bb272d11b0:M853e5a6fd4993355ec0b867f:1:6AJsPyaXfn5yRhnFAljVufhtFPdWC4Yu2dVN60cMBd4

You enquired about support for an architecture within Plan 9 on a Plan 9
list so the context was clear and I reply with the relevant architecture
string to help you locate it, but get a little lecture about Arm's naming
scheme (come to think of it, what are Thumb-1 and Thumb-2 called?).  Next
time, I'll insist on the 27B/6.

On Fri, 20 May 2022, 22:27 adr, <adr@sdf.org> wrote:

> On Fri, 20 May 2022, Charles Forsyth wrote:
>
> > Date: Fri, 20 May 2022 21:34:05 +0100
> > From: Charles Forsyth <charles.forsyth@gmail.com>
> > Reply-To: 9fans <9fans@9fans.net>
> > To: 9fans <9fans@9fans.net>
> > Subject: Re: [9fans] Aarch64 on labs|9legacy?
> >
> > It's called arm64
>
> From
> https://developer.arm.com/documentation/den0024/a/Introduction?lang=en
>
> "AArch64 is the name used to describe the 64-bit execution state
> of the ARMv8 architecture.  AArch32 describes the 32-bit execution
> state of the ARMv8 architecture, which is almost identical to ARMv7.
> GNU and Linux documentation (except for Redhat and Fedora distributions)
> sometimes refers to AArch64 as ARM64."
>
> I would agree that you could use the therm ARM64 as a synonym of
> Aarch64, but giving me just that response...  It isn't even funny.
>
> adr.

------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M853e5a6fd4993355ec0b867f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription




Sat May 21 18:13:48 EDT 2022
0x30330000+0x0050 -> 0x00000000
0x30330000+0x0050 <- 0x00000000 # iomuxc for gpio1, mux mode==0 gpio
0x30200000+0x0004 -> 0x3f004210
0x30200000+0x0004 <- 0x3f004610 # IDR gpio1 io10 -> output
0x30200000+0x0000 -> 0x22004b90
0x30200000+0x0000 <- 0x22004f90 # set gpio1 io10 high


0x30670000+0x0008 <- 0x00000000 # pwm idr 0
0x30670000+0x0000 <- 0x01c20000 # pwm cr
0x30670000+0x000c <- 0x00000000 # pwm sar (dity cycles)
0x30670000+0x0010 <- 0x0000ffff # pwm pr (period)
0x30670000+0x0000 -> 0x01c20000
0x30670000+0x0000 <- 0x01c20001 # pwm set enbale

0x30670000+0x000c <- 0x0000ffff # pwm change duty cycle
0x30670000+0x000c <- 0x00007fff # ...
0x30670000+0x000c <- 0x00003fff # ...


Thu May 19 12:59:43 EDT 2022
  ## Python 3 provider (optional)
    - INFO: Using: g:python3_host_prog = "$HOME/.config/nvim/py37/bin/python"
    - INFO: Executable:
    <REDACTED_BUT_DEFINITELY_VALID>/.config/nvim/py37/bin/python
    - INFO: Python version: 3.7.5
    - INFO: pynvim version: 0.4.3
    - OK: Latest pynvim is installed.


Thu May 19 12:34:21 EDT 2022
function
<SNR>53_filetype_changed[4]..remote#define#CommandBootstrap[1]..remote#host#Require[10]..provider#pythonx#Require[12]..provider#Poll,
line 6
Vim(let):E475: Invalid value for argument cmd: '' is not executable
Error detected while processing function
<SNR>53_filetype_changed[4]..remote#define#CommandBootstrap[1]..remote#host#Require[10]..provider#pythonx#Require[12]..provider#Poll:
line 17:
E605: Exception not caught: Failed to load python3 host.  You can try to see what
happened by starting nvim with $NVIM_PYTHON_LOG_FILE set and opening the generated
log file.  Also, the host stderr is available in
messages.
Error detected while processing function
<SNR>53_filetype_changed[4]..remote#define#CommandBootstrap[1]..remote#host#Require:
line 10:
E171: Missing :endif
Error detected while processing function <SNR>53_filetype_changed:
line 4:
E171: Missing :endif


Wed May 18 16:50:19 EDT 2022
#Colorset
Colorset 0 fg black, bg #cbdcca, hi white, sh #777777
Colorset 1 fg #777777, bg #cbdcca, hi white, sh black
Colorset 2 fg black, bg #cbdcca, hi white, sh black
Colorset 3 bg black, hi black, sh black

#Global style settings
Style * !ResizeOpaque, SnapAttraction 15 SameType ScreenAll, SnapGrid
Style * BorderColorset 3, HilightBorderColorset 3, !Handles
Style * BorderWidth 1, HandleWidth 1, !MWMButtons, MwmBorder
Style * Colorset 1, HilightColorset 2
Style * !Icon

#Window Decor
TitleStyle Centered Height 20 -- Flat
AddTitleStyle Vector 3 0x100@1 0x0@1 100x0@1
AddTitleStyle Vector 3 100-1px0@0 100-1px100-1p@0 0x100-1p@0
BorderStyle Simple
ButtonStyle All Simple
ButtonStyle 1 - MwmDecorMenu
ButtonStyle 4 - MwmDecorMax
ButtonStyle 6 - MwmDecorMin

# Title Buttons
Mouse 1 1 A Menu MenuWindowOps Delete
Mouse 1 2 A Close
Mouse 1 4 A Maximize 100 100
Mouse 2 4 A Maximize 0 100
Mouse 3 4 A Maximize 100 0
Mouse 1 6 A Iconify


Wed May 18 04:51:16 EDT 2022
#include <u.h>
#include <libc.h>
#include <draw.h>
#include <event.h>

char* options1[] = {"Middle Click", "", "Paste", "Snarf", "Exit", 0};
char* options2[] = {"Right Click", "", "Option3", "Option4", "Exit", 0};

Menu middlemenu = {options1};
Menu rightmenu = {options2};

void
eresized(int new)
{
	if(new&& getwindow(display, Refnone) < 0)
		sysfatal("can't reattach to window");
}

void
dopaste(void)
{
	int f;
	if((f = open("/dev/snarf", OREAD)) >= 0) {
		char body[30];
		read(f, body, 30);
		print("Paste: %s\n", body);
		close(f);
	}
}

void
dosnarf(void)
{
	int f;
	if((f = open("/dev/snarf", OWRITE)) >= 0) {
		char* body = "some text";
		write(f, body, strlen(body));
		print("Snarf: %s\n", body);
		close(f);
	}
}

void
main(int argc, char* argv[])
{
	USED(argc, argv);

	Event ev;
	int e;

	initdraw(0, 0, "Example: Menu");
	eresized(0);
	einit(Emouse);

	/* Main event loop */
	for(;;) {
		e = event(&ev);
		/* Middle Click */
		if((e == Emouse) && (ev.mouse.buttons & 3)) {
			if(emenuhit(2, &ev.mouse, &middlemenu) == 2)
				dopaste();
			if(emenuhit(2, &ev.mouse, &middlemenu) == 3)
				dosnarf();
			if(emenuhit(2, &ev.mouse, &middlemenu) == 4)
				exits(nil);
		}
		/* Right Click */
		else if((e == Emouse) && (ev.mouse.buttons & 4)) {
			if(emenuhit(3, &ev.mouse, &rightmenu) == 2)
				print("Pressed Option 3\n");
			if(emenuhit(3, &ev.mouse, &rightmenu) == 3)
				print("Pressed Option 4\n");
			if(emenuhit(3, &ev.mouse, &rightmenu) == 4)
				exits(nil);
		}
	}
}

next