Re: [9fans] Re: 9legacy rpi4 usb installation + 9front libsec + ...

[adr]

On Mon, 22 Nov 2021, Philip Silva via 9fans wrote:


An additional link: 
http://shithub.us/ph/misc/f54501c2592bd7cee283a243391d07f2dd131373/9legacy/f.html


Hey Philip, you need http://adr.freeshell.org/plan9/9legacylist,
the patches apply after those as shown in rpi4_usb_installation_example.

I'm glad you'll give it some use!

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T585a46c9a2003432-Mef27580c84b63b78e1a22591
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: 9legacy rpi4 usb installation + 9front libsec + ...

[adr]

On Mon, 22 Nov 2021, antonio@gmail.com wrote:

There is something in Internet Archive
https://web.archive.org/web/20211122091543/http://adr.freeshell.org/plan9/ but 
I think, it is not
complete.
Internet Archive is a great source for "Plan 9 archeology", for example:


The problem is that it stores the web site at the time it takes a
"snapshot", in this case I suppose someone made a search of
adr.freeshell.org in the wayback machine box.

I realized that
http://adr.freeshell.org/plan9/patches/sam_label_command_riosnarf.diff
was an old broken patch, and after updating it, I found a silly
bug while porting it to 9front (just some minutes before writing
this). Two people contacted me telling me they were going to archive
it, Vester "Vic" Thacker at

https://tip9ug.jp/who/adr/

and Philip Silva.

So in the future if you are a legacy|labs user and you want to use
it, better take a peak there.

I'm deleting it because I'm not going to use 9legacy as my base
system anymore, so it will rot with time.

If you are a Labs user, the most important patch is 9front_libsec,
it'll let you browse the web at least so well as in 9front at the
time I imported the cyphers. Importing 9front's mothra and webfs
is trivial if you don't like abaco. The png fix is worthy, I haven't
find any other png decoder with this limitation.

I think the usb installation example has some value too, for me
was a pain in the...

Regards,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T585a46c9a2003432-Mfca92abe135ac2380ad82a7e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: 9legacy rpi4 usb installation + 9front libsec + ...

[adr]

On Mon, 22 Nov 2021, adr wrote:


http://shithub.us/ph/misc/f54501c2592bd7cee283a243391d07f2dd131373/9legacy/f.html


Also better update 
http://adr.freeshell.org/plan9/patches/sam_label_command_riosnarf.diff, it had 
a bug.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T585a46c9a2003432-M684974f3e6aef6a72e62a029
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] 9legacy rpi4 usb installation + 9front libsec + ...

[adr]

I'm not using 9legacy anymore, but someone could find this useful.

I'll keep it in my sdf space for a while. Grub it now if you are going
to use it, I'll delete it in a week or so (I'm not interested in feedback).

http://adr.freeshell.org/plan9/

Regards,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T585a46c9a2003432-Mc9a99f28a9693f2070fdf615
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: 9legacy rpi4 usb installation + 9front libsec + ...

[adr]

I updated 
http://adr.freeshell.org/plan9/patches/sam_label_command_riosnarf.diff, it was 
bad formatted.

I'll keep the site to not pollute more the list.

Regards,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T585a46c9a2003432-M8021030c08d908fdd7d95ea9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Fix sam regexp bug with metacharacters in classes

[adr]

The code assumes runes are 16 bits long, not 21, creating faulting
code parsing classes. I.e. '/[\-]' will not match '-'.

This is the same fix already in 9front.

http://adr.freeshell.org/plan9/patches/sam_fix_metachars_on_classes.diff

--- /sys/src/cmd/sam/regexp.c   Tue Apr 23 19:06:01 2013
+++ regexp.cTue Nov 23 15:01:18 2021
@@ -53,8 +53,8 @@
 /*
  * Actions and Tokens
  *
- * 0x100xx are operators, value == precedence
- * 0x200xx are tokens, i.e. operands for operators
+ * 0x2000xx are operators, value == precedence
+ * 0x3000xx are tokens, i.e. operands for operators
  */
 enum {
   OPERATOR = Runemask+1,  /* Bitmask of all operators */
@@ -462,7 +462,8 @@
   exprp++;
   return '\n';
   }
-   return *exprp++|(Runemax+1);
+   /* add a flag so metacharacters aren't interpreted */
+   return *exprp++|(Runemask+1);
   }
   return *exprp++;
 }
@@ -498,11 +499,12 @@
   if((c2 = nextrec()) == ']')
   goto Error;
   classp[n+0] = Runemax;
-   classp[n+1] = c1;
-   classp[n+2] = c2;
+   /* remove possible flag from nextrec() */
+   classp[n+1] = c1 & Runemask;
+   classp[n+2] = c2 & Runemask;
   n += 3;
   }else
-   classp[n++] = c1;
+   classp[n++] = c1 & Runemask;
   }
   classp[n] = 0;
   if(nclass == Nclass){


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tccbdb20b670003a1-M5d4e6bea6c6908b388e51f0c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[adr]

On Sat, 29 Jan 2022, Steve Simon wrote:

search ebay for beatus mouse


Thanks, it's funny the three of us were talking about the same mouse.

https://www.amazon.co.jp/-/en/Beatus-Button-Perfect-Buttons-Scroll/dp/B07CZ1B7H3/ref=sr_1_3?crid=3VAGF8O45TNZW

https://www.ebay.com/itm/333469354375?epid=9032602165=item4da4528987:g:CwsAAOSwTh1eJWZm


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-M5ae5bd309f1514f87fe405ae
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[adr]

Trackballs also often have more than two real buttons.
umbraticus


The good 3 buttons mouses are vanishing, I've been thinking on
giving a try to a trackball for a while. The problem is that the
small ones seem to me like a pain to point, and the large ones look
like hard to make chords with the big ball in the middle. Could you
share your experience?

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-Md0e53e97477d447dbdd8df36
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[adr]

On Fri, 28 Jan 2022, umbrati...@prosimetrum.com wrote:


I use a Kensington Expert which I guess falls into the big


That's funny, it's the very same I was looking at.

aliexpress.com/item/1005001848991454.html


The scrollwheel thing is pretty nice too.


Three button mice with lateral scrollwheel are even harder to
find. That's why I ended up with this cheap one:

aliexpress.com/item/404785639.html

It's not so bad, the plastic feels a little cheaper than one from
hp or ibm but cost less than half the price... and it is very
accurate, really.  It enters sleep mode to save battery (you can't
disable this) and the only way to wake it is clicking one of the
buttons (not the wheel). Now the funny part: it sends the click to
the host. A nightmare.

Thanks for the feedback,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-Mcae193567503385d419fed55
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation:

[adr]

ori wrote:

All too often, the only post with technical content
is the first post in a thread.  The technical content
is drowned in the bullshit.

As a result, help is given off-list if it's given at
all.  It protects the questioner from the deluge of
noise, but hides any debugging steps from anyone who
could learn from them.


This is just surreal.

The _questioner_ used the list to denounce politically another
member (well, I don't think nemo is here anymore), but instead of
a warning by the administrator it gets a pat on the back by other
members. Ah! and the bullshit is in the ones who got outraged.

Imagine I post that you are a fascist and that because of that we
need another git client. I'm sure the same people that have been
trolling in this thread would be defending you.

The only explanation I see here is a tribal one.

I don't like that.

I'll keep myself out of it, I've only made a fool of myself.

PS. If you want to stop a discussion, don't put more fire on it.
You are not the moderator, people don't like being told to shut up
by another member. Russ said us to shut up and look at us...

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T47361f1c7a89aa15-Md6c5c6fd71e0a10711815b0d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Corrupt subjects

[adr]

I noticed that some mails were sent by me with corrupt subjects. I'm
using alpine again and it's very easy to do that after editing with
vi (I'm using the sdf shell directly).

Sorry about that, it looks like I was tring to separate the thread,
I wasn't.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2ad9964970e367f9-Mbb2a4fa87b8a6cebcc8dbb56
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[adr]

fijal wrote:

I'm very happy with this one:  http://www.hao1885.com/products_desc.asp?id=413


That's the same I was talking about. Don't you feel annoyed when
you have to wake it? Do you know where to buy the wired model?

hao1885.com/products_desc.asp?id=414

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-M301ed10a9c39815211dacdb6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Problems installing 9legacy on bare metal (Thinkpad X60)

[adr]

On Mon, 24 Jan 2022, Lucio De Re wrote:


Date: Mon, 24 Jan 2022 05:23:26 +0200
From: Lucio De Re 
Reply-To: 9fans <9fans@9fans.net>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] Problems installing 9legacy on bare metal (Thinkpad X60)

On 1/23/22, Conor Williams  wrote:

hello mein names ist __insert name here___

this is not a 9front mailing list

It isn't, but unless *all* 9front users and fans (need not be one
homogenous group) choose to stop using this list, I have no objection
to assisting them or learn from them. I don't think I'm alone in this.


ps: this is ...
when it was setup there was no 9front
9front is a breakaway republic designed to initially enhance P.8.72...
pps: the problem with break-away republic is that they may initially
have the best of intentions but soon realise that they may not
have the resources... a bit like my friend sam... /c:2022Jan23


Thank you for the history lesson and the political savvy. Can we get
on with the main topic, now?

Lucio.


You are aware that you are talking to the most stupidly writen bot
in the history of the _I've_no_life_some_one_pay_me_attention_please_
retards?

There is an episode of South Park when some poor kid get
all exited because one person makes him a friend on facebook. You
made some really lonely sad piece of Mr. Hankey happy today.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb5aaf646618a421a-M207c983dbe2bd679ace6fd68
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundationy

[adr]

People has different points of view about how sociaty is organized.
This can change with time along the way of ones life, sometimes
not. The only way you can promote ideas you think are best for the
future is through dialog, engaging _all_ different kinds of people
in the conversation.

There is a trend now which has came up thanks to the application
of technology to the most stupid behavior of people in general,
the so called social media. This allows people who doesn't do really
anything for anyone to pretend to others and themselves that they
are some kind of brave justice warriors, but acting in the most
cowardly way, twisting words getting them out of context, making
up _rules_ so they can justify attacks and insults to the next poor
bastard. Yes, the next because there is going to be another one,
always.

Witnessing this on this mailing list makes me sick.

One thing I like of old school computer science mailing list is
that complete different people engage in conversations and work
together no matter what political views these people have. There
is room for some healthy discussion on these matters, and normally
it ends by itself when boundaries are crossed. I've seen this
discussions in other lists, and always -when no child(mental) are
involved- there is an effort to keep a friendly atmosphere at the
end.

I've read the books of Ballesteros. Yes, say the name you coward.
The only thing I can say about them is that they need a revision
to a most correct English. Is not easy when you are not a native
speaker. I can notice it when I read it, but I can make the same
mistakes in this very same mail I'm writing.

Maybe some native speaker could help on this.

"support oppression"
"maybe I have heard secondhand"
"fight against right wing ideas"

You see, I don't know you, either Ballesteros, and maybe I would
agree more with the ideas you could _recite_ over a cup of coffee,
but I'm pretty sure a conversation with Ballesteros (whatever ideas
he has) would be more exiting and productive.

This "Tell me only what I want to hear, or we'll ban you" crap...

I think you are not bipolar, you are just another piece of Mr. Hankey.

This list is becoming a South Park Christmas special...

https://www.youtube.com/watch?v=J_IMpq_pCvo


Date: Mon, 24 Jan 2022 05:12:10 -0600
From: mycroftiv 9gridchan 
Reply-To: 9fans <9fans@9fans.net>
To: 9fans@9fans.net
Subject: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation

Hi 9fans, Got some new ideas im excited about right now.
Apparently the author of the well-known 'intro to OS abstractions'
book has political views that are not cool and support oppression
maybe I have heard secondhand.
We need a better book to introduce people to 9.
I'd like to see something created that talks about all forms of 9 and
of the ANTS variant especially since if im bipolar and spending my
money to try to help plan 9, im obviously also gonna be hyping my
stuff along with trying to fight against right wing ideas.
The cause to make plan 9 an accepting welcoming community for all
humans requires good information resources and support.
The funny-named organization I just thought up, The Flan 9 Poundation,
offers a bounty from me personally of at least $200 for producing this
content. The name is an obvious namespace pun. We want to work in a
friendly way with everyone but we also want good stuff and peace and
support for minority trans disabled mentally wacked out
counterculture.

Peace and love and lets make Plan 9 amazing and full of rainbow love,
JenBen


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta19a0d2cb0bf4182-M3069d4cdbbd64a90c45af218
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation

[adr]

On Tue, 25 Jan 2022, Lucio De Re wrote:


Microftiv deserves the same kind of respect as Nemo and I think - he
can correct me in private if I'm mistaken, I'll publish the correction
if requested to - the former meant to express that respect, but his
subconscious nabbed him.

I also feel the pressure of wanting to work with like minded people,
it's a strong emotional challenge and isn't exactly unjustified. In
fact, this mailing list comes closest to my comfort zone precisely
because Plan 9 is a choice, not a fashionable one.

One could be even more materialistic, but that's not necessary, just
accept that Microftiv was being defensive, without realising he verged
beyond the offensive.

As for everyone else needing to voice an opinion - including myself -
what is your excuse for insulting people of whom you know only one
facet of their personality?

Lucio.


Insulting people... First this moron that is polluting the mailing
list with his stupid bot. It can be funny to you now, wait some
time when you'll try to search the archives.

Then this person starts with this social justice hunting crap,
attributing political views to a plan9 contributor because "maybe
I have heard secondhand..." and then trying to censor his book
"[...]support oppression[...]", the most complete introductory book
to plan9 (language faults apart) that exists nowadays. For those
who don't know, he wrote also an extensive commentary to the Plan
9 source code following John Lions' style, there is nothing like
that anywhere else.

And now he is a victim.

And all the trolling around... give me a break.

I don't know J. Ballesteros. I don't know what are his political
views. I don't bloody care. This is not a twitter morons'
group.

Just for curiosity, in what thread people has been harassed here
for race, sexual orientation, disablility or whatever you want to
add to the list social champion?

A decade ago this list was still a pleasant space, with the typical
well known trolls vomiting now and then, yes, but still full of
knowledge and good spirits.

I don't think there is a point to be subscribed to what is left of
9fans anymore.

Sorry Rux Cox, last reply.

Bye.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T627a29a7babaf29e-Mf4c9cfe9eb5677c43c321304
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation

[adr]

On Tue, 25 Jan 2022, hiro wrote:


adr, you seem overly invested only judging from the amount of text,
where you counter politics, with more politics, and shitty extremely
uninformed rhetorics.


Can you at least respect the administrator of the list and wait to
another threat to troll as usual?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T627a29a7babaf29e-M36ffde7668d460c8a1d60a60
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

RE: [9fans] Unable to load page in Abaco

[adr]

On Tue, 25 Jan 2022, Saif Resun wrote:

DNSSERVER=8.8.8.8

also produced the same error.


Hi Saif, as cinap said this var is used by ndb/dns. Look I didn't
want to participate in this thread beacuse I don't have a Bell's
Plan9|legacy installation right now, but you are going to found the
same problems I hit then, the most important is the lack of ciphers.
I imported them from 9front while I was using 9legacy. also you need
to fix webfs: extend the URL length and add SNI.

You can grab it from http://adr.freeshell.org/plan9/patches/ and adapted
at your taste, but note that I'm not mantaining it.

Now you want to ask yourself, is it worth it? Why don't use 9front instead?

Good luck,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1be0869af45e66b9-M2171725f445f786aaf1bfdfb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Conversion of constants in C compiler

[adr]

On Wed, 20 Apr 2022, Charles Forsyth wrote:


The short answer is whatever the historical reasons for the current 
interpretation(s), it
should follow C99 rules to avoid confusion.


This should do the trick. I hope to not have to send another patch in half an 
hour...

Charles, you are part of the p9f board, if you serve the 9legacy
sources there it would be really easy to send you a patch. In my
opinion it makes more sense to let the editions be archived as isos
and substitute the sources 9p service with a 9legacy one.

Just a suggestion,
adr.
/sys/src/cmd/cc/lex.c:
[...]
   vv = yylval.vval;
   if(c1 & Numvlong ||
 convvtox(vv, TUVLONG) > convvtox(vv, TULONG) ||
 (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TLONG) < 0) {
   if((c1 & Numuns) || convvtox(vv, TVLONG) < 0) {
   c = LUVLCONST;
   t = TUVLONG;
   goto nret;
   }
   c = LVLCONST;
   t = TVLONG;
   goto nret;
   }
   if(c1 & Numlong ||
 convvtox(vv, TULONG) > convvtox(vv, TUINT) ||
 (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TINT) < 0) {
   if((c1 & Numuns) || convvtox(vv, TLONG) < 0) {
   c = LULCONST;
   t = TULONG;
   goto nret;
   }
   c = LLCONST;
   t = TLONG;
   goto nret;
   }
   if((c1 & Numuns) || convvtox(vv, TINT) < 0) {
   c = LUCONST;
   t = TUINT;
   goto nret;
   }
   c = LCONST;
   t = TINT;
   goto nret;

nret:
   yylval.vval = convvtox(vv, t);
   if(yylval.vval != vv){
   nearln = lineno;
   warn(Z, "truncated constant: %T %s", types[t], symb);
   }
   return c;
[...]

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T22754f10b241991c-Mabed3218d4cc85a6f48f03f7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Conversion of constants in C compiler

[adr]

Hi.

I've been tinkering again with the dist I shared before in
http://adr.freeshell.org/plan9, basically 9legacy + Miller's 9pi
+ 9front's libseq. Importing ori's git9 I noticed that the compiler
was truncating a constant without the correspondent suffix.

According to C99, the type of a constant should be the first in
which its value can be represented following this table:

Suffix Decimal 0 or 0x
--
none   int int
   long intunsigned int
   long long int   long int
   unsigned long int
   unsigned long long int
--
u|Uunsigned intunsigned int
   unsigned long int   unsigned long int
   unsigned long long int  unsigned long long int
--
l|Llong intlong int
   long long int   unsigned long int
   long long int
   unsigned long long int
--
u|U & l|L  unsigned long int   unsigned long int
   unsigned long long int  unsigned long long int
--
ll|LL  long long int   long long int
   unsigned long long int
--
u|U & ll|LLunsigned long long int
--

Which follows the K description at "A.2.5.1 Integer Constants", just adding 
LL.

Now, in plan9 constants are of type int if there is no suffix, or
of the one specified by the suffix. The only change made is from
a signed type to an unsigned one if it is necessary to fit the
constant's value. The rest is truncated:

/sys/src/cmd/cc/lex.c:
[...]
   vv = yylval.vval;
   if(c1 & Numvlong) {
   if((c1 & Numuns) || convvtox(vv, TVLONG) < 0) {
   c = LUVLCONST;
   t = TUVLONG;
   goto nret;
   }
   c = LVLCONST;
   t = TVLONG;
   goto nret;
   }
   if(c1 & Numlong) {
   if((c1 & Numuns) || convvtox(vv, TLONG) < 0) {
   c = LULCONST;
   t = TULONG;
   goto nret;
   }
   c = LLCONST;
   t = TLONG;
   goto nret;
   }
   if((c1 & Numuns) || convvtox(vv, TINT) < 0) {
   c = LUCONST;
   t = TUINT;
   goto nret;
   }
   c = LCONST;
   t = TINT;
   goto nret;

nret:
   yylval.vval = convvtox(vv, t);
   if(yylval.vval != vv){
   nearln = lineno;
   warn(Z, "truncated constant: %T %s", types[t], symb);
   }
   return c;
[...]

9front introduces some widening:
[...]
   vv = yylval.vval;
   /*
* c99 is silly: decimal constants stay signed,
* hex and octal go unsigned before widening.
*/
   w = 32;
   if((c1 & (Numdec|Numuns)) == Numdec)
   w = 31;
   if(c1 & Numvlong || (c1 & Numlong) == 0 && (uvlong)vv >= 1ULL

Re: [9fans] Conversion of constants in C compiler

[adr]

On Wed, 20 Apr 2022, o...@eigenstate.org wrote:

When you have a patch, let me know -- I'll happily test
and apply to 9front.


Hi ori, this patch applyes to the sources served at 9front.org.
By the way, do you plan to keep in sync
http://only9fans.com/ori/git9/HEAD/info.html or should I forget
about that repo?

Regards,
adr.

--- /n/9front/sys/src/cmd/cc/lex.c  Wed Apr  6 14:45:26 2022
+++ /tmp/lex.c  Thu Apr 21 08:39:14 2022
@@ -848,16 +848,9 @@
   yyerror("overflow in constant");

   vv = yylval.vval;
-   /*
-* c99 is silly: decimal constants stay signed,
-* hex and octal go unsigned before widening.
-*/
-   w = 32;
-   if((c1 & (Numdec|Numuns)) == Numdec)
-   w = 31;
-   if(c1 & Numvlong || (c1 & Numlong) == 0 && (uvlong)vv >= 1ULL< convvtox(vv, TULONG) ||
+ (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TLONG) < 0) {
   if((c1 & Numuns) || convvtox(vv, TVLONG) < 0) {
   c = LUVLCONST;
   t = TUVLONG;
@@ -867,7 +860,9 @@
   t = TVLONG;
   goto nret;
   }
-   if(c1 & Numlong) {
+   if(c1 & Numlong ||
+ convvtox(vv, TULONG) > convvtox(vv, TUINT) ||
+ (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TINT) < 0) {
   if((c1 & Numuns) || convvtox(vv, TLONG) < 0) {
   c = LULCONST;
   t = TULONG;
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T22754f10b241991c-Mefe97ddcd27aad8f1a072269
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
--- /n/9front/sys/src/cmd/cc/lex.c	Wed Apr  6 14:45:26 2022
+++ /tmp/lex.c	Thu Apr 21 08:39:14 2022
@@ -848,16 +848,9 @@
 		yyerror("overflow in constant");
 
 	vv = yylval.vval;
-	/*
-	 * c99 is silly: decimal constants stay signed,
-	 * hex and octal go unsigned before widening.
-	 */
-	w = 32;
-	if((c1 & (Numdec|Numuns)) == Numdec)
-		w = 31;
-	if(c1 & Numvlong || (c1 & Numlong) == 0 && (uvlong)vv >= 1ULL< convvtox(vv, TULONG) ||
+	  (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TLONG) < 0) {
 		if((c1 & Numuns) || convvtox(vv, TVLONG) < 0) {
 			c = LUVLCONST;
 			t = TUVLONG;
@@ -867,7 +860,9 @@
 		t = TVLONG;
 		goto nret;
 	}
-	if(c1 & Numlong) {
+	if(c1 & Numlong ||
+	  convvtox(vv, TULONG) > convvtox(vv, TUINT) ||
+	  (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TINT) < 0) {
 		if((c1 & Numuns) || convvtox(vv, TLONG) < 0) {
 			c = LULCONST;
 			t = TULONG;

Re: [9fans] void*

[adr]

On Sun, 15 May 2022, o...@eigenstate.org wrote:

On Sun, 15 May 2022, arn...@skeeve.com wrote:


It allows you pass pointers of any type without requiring casts:

   struct foo s[5] = ...
   memmove(s, & s[1], 4 * sizeof(struct foo)); // shift down 1

The compiler won't complain because any pointer type can be passed
to a void* parameter.  Otherwise you'd need to cast:

   memmove((uchar*) s, (uchar*) & s[1], 4 * sizeof(struct foo));


Sure, but you could change it to do the same with char*.



char* has legitimate uses for things other than generic pointers,
and the conversion complaints catch bugs.


My point here is that It makes more sense to me to use a generic
pointer which have a size (the type it points) of 1, so arithmetic
can be applied to it. Of course I'm not proposing to change the
compiler and all the code. It was just a reflection. Allowing
arithmetic on void* solves the problem. Reading the definition of
void this could look incongruous, but C99 already specifies:

"A pointer to void shall have the same representation and alignment 
requirements as a
pointer to a character type"

So I don't see any real trouble to allow the same operations as with char*.

Again, just some thoughts. The comments about uchar* or uint8* are
because arithmetic on void* brakes the concept of void, I don't
really like it.  But sometime things are doomed to staid as they
are, even if they don't make sense...

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M7092e86f1d4c6f710af49d81
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] void*

[adr]

In case someone is asking why this guy is suddenly so thoughtful
about void pointers, it is because I'm porting Ali Gholami Rudi's
neatroof, and he uses a lot of arithmetics with void* in neatmkfn.
I got rid of ape, and this troff looks really easy to port and has
a lot of features. I'll share it when it's working in case someone
is interested.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M683ed8fb049de7a5d4457cbf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] void*

[adr]

Hi,
one of the first thing I noticed compiling in plan9 is that arithmetic
on void* is illegal. Other compilers treat void* as uchar*.
Conceptually, it  makes sense. A pointer to void doesn't point to
any object. But then I've seen the use of void* in functions (like
memccpy) when the pointed object is going to be processed as a
byte array. Local uchar*'s are used to do the trick inside the
function.

It wouldn't make more sense to avoid the use of void*
and just use instead uchar* or better still u8int*?

Some thoughts?

Regards,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M7d5d7a58e7e77b74d2aa123a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] void*

[adr]

What I mean is if we are going to follow C99 in the use of void*,
we should allow arithmetic on them. If not, there is not point to
use void* as char*, just use char* as the generic pointer. When I
ask something here about the Plan9 compilers, I'm not asking about
some committee's standard, I have access to them, like everyone
else.

By the way I'm curious, someone knows a modern machine with
CHAR_BIT>8? I would prefer to use fixed-width types and let the
compiler deal with these (nowadays) eccentricities.

Regards,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M3ffa29ce3e6bd94227835bd6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] void*

[adr]

On Sun, 15 May 2022, adr wrote:


What I mean is if we are going to follow C99 in the use of void*,
we should allow arithmetic on them.


Let me be clear, I know that C99 requires the pointer to be a
complete object type to do arithmetic, and I like that, is consistent.
But then I don't see the point to use void* as a generic pointer.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M1f0eaeec24bbe0f8c2c06b0f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] void*

[adr]

On Sun, 15 May 2022, arn...@skeeve.com wrote:


It allows you pass pointers of any type without requiring casts:

   struct foo s[5] = ...
   memmove(s, & s[1], 4 * sizeof(struct foo)); // shift down 1

The compiler won't complain because any pointer type can be passed
to a void* parameter.  Otherwise you'd need to cast:

   memmove((uchar*) s, (uchar*) & s[1], 4 * sizeof(struct foo));


Sure, but you could change it to do the same with char*.


void* has been standard practice (even on Plan 9) for 30+ years.
It's not worth changing it now. :-)


I agree, I just wanted to share some opinions.

Regards,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M9bc3acdf4dd19efb75ea5a51
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Aarch64 on labs|9legacy?

[adr]

Hi,

has someone done something with aarch64 on labs|9legacy?

Regards,
adr.

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

Re: [9fans] Aarch64 on labs|9legacy?

[adr]

On Fri, 20 May 2022, Charles Forsyth wrote:


Date: Fri, 20 May 2022 21:34:05 +0100
From: Charles Forsyth 
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-M5cf852a151255c694f902925
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[adr]

On Sat, 21 May 2022, o...@eigenstate.org wrote:

aaarch64


Thanks, really helpful.

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

Re: [9fans] Aarch64 on labs|9legacy?

[adr]

On Sat, 21 May 2022, Aram H?v?rneanu wrote:

Since Charles wrote the arm64 compiler, he can call it whatever he wants.


I wasn't talking about any compiler. Yes, you can call your compiler
whatever you want. You can call it shitarm, just don't tell me that
the 64-bit Armv8-A architecture is called that (well, if you were
used to programming in A32 assembly and now you have to do it in
A64, I think you could call it _that_).

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

Re: [9fans] Aarch64 on labs|9legacy?

[adr]

On Sat, 21 May 2022, Aram H?v?rneanu wrote:


On Sat, May 21, 2022 at 7:12 PM adr  wrote:

I wasn't talking about any compiler.


Choosing $objtype (and $O, etc) is the first thing someone writing
a new Plan 9 compiler port does. These values are set in libmach.
I suggest reading the 2c(1) manual page, as well as the Plan 9
compiler papers which explain how the Plan 9 compiler works.


What on Earth are you talking about? The name of the architecure,
that was the subject of the two little messages I exchanged with
Charles, do you really think that when I said AArch64 I was reffering
to the name choosen for plan9 (9front?, there is no AArch64 support
in labs|9legacy) port?


With this new information you will know what even if you didn't
think you were talking about the compiler, you were actually talking
about decisions made in the compiler when you were asking about
Plan 9 on some architecture or another.

It is fine if you do not agree with these decisions.


Again, what on Earth are you talking about?, A simple question, so
bloody simple and again as usual the same... you know what, just
forget it, please, everyone, just forget it.

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

Re: [9fans] Aarch64 on labs|9legacy?jj

[adr]

On Sat, 21 May 2022, Frank D. Engel, Jr. wrote:


The compiler appears to be called 7c.

adr, looking at the original email on this thread, it is not very clear what 
you are trying to ask?


There is no 7c on labs' , there is no patch for aarch64, arm64 or
whatever you want to call it in 9legacy. There is no kernel for
any aarch64 machine on labs/legacy. Seriously, what is so hard to
understand in this frase:

 has someone done something with aarch64 on labs|9legacy?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7409a8df6326c959-Me5fa713e684fc24bd81b552f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[adr]

On Sun, 22 May 2022, Thaddeus Woskowiak wrote:

You've embarrassed yourself enough already. Please end this tantrum.


Thaddeus, you can go and plumb yourself, and you can keep your stupid
basket of arm computers. Yours was the most embarrassing "I'm just
bored and I don't have anything else to do" response of all.

More than two dozen responses, none related to the question.

Haven't you done anything with aarch64 on labs|9legacy?

You don't know anyone who has done that?

Then why are you posting to this thread?

Trolling and bullshit, as always.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td5407cac4afa27f1-M8defdb2760a65fe2b29e7092
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[adr]

Just in case somebody arrives here with interest in the subject of
the thread, here are the portable version of the plan9 compilers,
including 7*, which someone shared with me offlist.

https://bitbucket.org/plan9-from-bell-labs/9-cc/

It was really hard to type this, don't warry, I understand.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td5407cac4afa27f1-M75e98414a33f1b533faa1cde
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Aarch64 on labs|9legacy?

[adr]

Oh man, hiro, you always running to the fun... but sometimes I
don't know if you are smoking something good (let me know) or if
it is that you just don't even bore to read the threads before
jumping in anymore.

I don't have any problem with the name of the port, I've used the
pi4 port of cinap in 9front a lot. I was asking explicitly about
labs|9legacy because that would be more easy to use in my local
dist.

I don't have any problem with the people at 9front, stop spreading
bullshit, I'm using fossil and shrinking the system a lot (e.g. I
got rid of ape for real), if not I would be using 9front. For me
is just easiest (and it helps me to understand better the system) to
import what I need or like.


maybe go back to playing with your new macbook? there's good customer
support for that.


Good troll skills, but you are not dealing with a young hipster,
I'm a middle-aged man who never have bought an overpriced piece of
fashion-tech-crap like that in my life. And before you try another
piece from your popular repertoire, I don't use twitter, facebook,
instagram, 

Now put yourself in my pants. A simple question. Look at the thread.
Look at the thread!

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td5407cac4afa27f1-M44b3a54d41932ce32d3104fc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[adr]

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

[9fans] ntohl, htonl,

[adr]

Hi,

I'm getting rid of ape but I need the functions at
/sys/src/ape/lib/bsd/ntohl.c to port some software. These functions
just change endianness. Is there some native similar functions
somebody is aware of? lookman is not helping me here. I don't want to add code
if a similar functionality is already in the system.

Regards,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tbf58310b561cd180-M2eabe8ea5d75da927a0a19b4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] ntohl, htonl,

[adr]

data in a determinded endianness, so I imagined that some functions

I mean "certain" endianness, ugly typo.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tbf58310b561cd180-M6768de0bfccdc64669e77a6f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] ntohl, htonl,

[adr]

On Fri, 13 May 2022, o...@eigenstate.org wrote:


Date: Fri, 13 May 2022 10:22:13 -0400
From: o...@eigenstate.org
Reply-To: 9fans <9fans@9fans.net>
To: 9fans@9fans.net
Subject: Re: [9fans] ntohl, htonl, 

Quoth Alex Musolino :

I'm getting rid of ape but I need the functions at
/sys/src/ape/lib/bsd/ntohl.c to port some software.  These functions
just change endianness.  Is there some native similar functions
somebody is aware of?  lookman is not helping me here.  I don't want
to add code if a similar functionality is already in the system.


No. Those functions are mental.  The Plan 9 way is so simple that
there's no library, everyone just brings their own macros/functions.
The trick is: if you care about the order of bytes then you should be
dealing with a byte array, not a native integral type.


see also:

https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html


Oh, I agree with that and I think this was a key in the design of
9p. I wasn't asking for the existence of those functions elsewhere,
but for some common code to change endianness of some data structure,
stream, etc. Not because is hard to do, just to not repeat the same
code again and again. Every format of image, audio, etc store
data in a determinded endianness, so I imagined that some functions
or macros could be defined already somewhere.

Regards,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tbf58310b561cd180-Mf37677730df2f6e32e400995
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] ntohl, htonl,

[adr]

On Fri, 13 May 2022, o...@eigenstate.org wrote:

They exist in fcall.h -- see GBIT/PBIT macros.


Thanks.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tbf58310b561cd180-Mb43211fb858857f5155bf1cb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] void*

[adr]

On Mon, 16 May 2022, Charles Forsyth wrote:

it's void* because that can be assigned between other pointer types without a 
cast.x = malloc(sizeof(*x));
instead of x = (T*)malloc(sizeof(*x)); which just adds clutter.
Similarly it's just free(x) instead of free((void*)x); (or free((uchar*)x) as I 
understand your
suggestion).


The idea I wanted to share, more as a light chat than as a suggestion
is that I would find more useful to have a generic pointer (with
the property you have just described) with size (the object pointed
to) of 1. I don't expect anyone to be happy about substituting
void*. GNU (and I think clang followed suit) just made the size of
void* 1. I don't really like this because it breaks the concept of
void, that's the reason I talk about char* and uint8*. But I think
I'm repeating my self a lot, so I will silently retreat back through
the hedge.

Regards,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M95c0625b8879224f86e28cd8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Tue, 28 Jun 2022, adr wrote:

It's just to play with it, note that onnote should be just passed
once.  I'll post another patch if things work ok.


Here it is. I'm doing sysfatal when malloc fails to be coherent
with the rest of libthread, but I don't think that's a good approach.
When those functions fail to make an allocation they should return
an error so the program could take an action depending on the error.
For example, if there is no sufficient memory at a time, the program
could wait until there are enough resources to spawn a new thread.

adr
--- /tmp/main.c
+++ /sys/src/libthread/main.c
@@ -28,6 +28,10 @@
   _qlockinit(_threadrendezvous);
   _sysfatal = _threadsysfatal;
   __assert = _threadassert;
+   onnote = mallocz(PPCHUNK*sizeof(uintptr), 1);
+   if(!onnote)
+   sysfatal("Malloc of size %d failed: %r", 
PPCHUNK*sizeof(uintptr));
+   onnotesize = PPCHUNK;
   notify(_threadnote);
   if(mainstacksize == 0)
   mainstacksize = 8*1024;
--- /tmp/note.c
+++ /sys/src/libthread/note.c
@@ -5,7 +5,6 @@

 int   _threadnopasser;

-#defineNFN 33
 #define   ERRLEN  48
 typedef struct Note Note;
 struct Note
@@ -17,62 +16,157 @@

 static Note   notes[128];
 static Note   *enotes = notes+nelem(notes);
-static int (*onnote[NFN])(void*, char*);
-static int onnotepid[NFN];
+Onnote **onnote;
+int onnotesize;
+static int (*onnoteall[NFN])(void*, char*);
 static Lock   onnotelock;

 int
 threadnotify(int (*f)(void*, char*), int in)
 {
-   int i, topid;
-   int (*from)(void*, char*), (*to)(void*, char*);
+   int i, j, n;

-   if(in){
-   from = nil;
-   to = f;
-   topid = _threadgetproc()->pid;
-   }else{
-   from = f;
-   to = nil;
-   topid = 0;
-   }
   lock();
-   for(i=0; i -1)
+   onnoteall[n] = f;
+   unlock();
+   return n>-1;
+   }
+
+   /* remove note for all processes */
+   if(in == -1){
+   for(i=0; ipid==_threadgetproc()->pid){
+   for(j=0; jfn[j] == f){
+   onnote[i]->fn[j] = 0;
+   break;
+   }
+   }
+   unlock();
+   return jpid==_threadgetproc()->pid){
+   n = -1;
+   for(j=0; jfn[j] == f){
+   unlock();
+   return 1;
+   }
+   if(onnote[i]->fn[j]==nil && n==-1)
+   n = j;
+   }
+   if(n > -1)
+   onnote[i]->fn[n] = f;
+   unlock();
+   return n>-1;
+   }
+   /* there is a free slot */
+   if(!onnote[i] && n==-1)
+   n = i;
+   }
+   /* there is no free slot */
+   if(n == -1){
+   onnotesize += PPCHUNK;
+   onnote = realloc(onnote, onnotesize*sizeof(uintptr));
+   if(!onnote){
+   unlock();
+   sysfatal("Malloc of size %d failed: %r", 
onnotesize*sizeof(uintptr));
+   }
+   memset(onnote+i+1, 0, PPCHUNK-1); 
+   n = i;

+   }
+   onnote[n]=mallocz(sizeof(Onnote), 1);
+   if(!onnote[n]){
+   unlock();
+   sysfatal("Malloc of size %d failed: %r", sizeof(Onnote));
+   }
+   onnote[n]->pid = _threadgetproc()->pid;
+   onnote[n]->fn[0] = f;
+   unlock();
+   return 1;
+}
+
+void
+threadcancelnotes(int pid)
+{
+   int i;
+
+   lock();
+   for(i=0; ipid==pid){
+   free(onnote[i]);
+   onnote[i] = nil;
   break;
   }
   unlock();
-   return ipending)
   return;

   p->pending = 0;
+   all = j = 0;
   for(n=notes; nproc == p){
-   strcpy(s, n->s);
-   n->proc = nil;
-   unlock(>inuse);
-
-   for(i=0; ipid || (fn = 
onnote[i])==nil)
-   continue;
-   if((*fn)(v, s))
-   break;
+   for(i=0; is)){
+   all = 1;
+   break;
+   }
+   if(!all){
+   

[9fans] _threadmalloc() size>100000000; shouldn't be totalmalloc?

[adr]

/sys/src/libthread/lib.c

[...]
void*
_threadmalloc(long size, int z)
{
   void *m;

   m = malloc(size);
   if (m == nil)
   sysfatal("Malloc of size %ld failed: %r", size);
   setmalloctag(m, getcallerpc());
   totalmalloc += size;
   if (size > 1) {
   fprint(2, "Malloc of size %ld, total %ld\n", size, totalmalloc);
   abort();
   }
   if (z)
   memset(m, 0, size);
   return m;
}
[...]

Shouldn't the if statement test the size of totalmalloc before the
abort? That size, 100M for internal allocations? It has to be
totalmalloc, doesn't it? If not this if statement should be after
testing the success of the malloc. Am I missing something?

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te1be8dc72738258d-M704d54262c512e9fce0f9fae
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: _threadmalloc() size>100000000; shouldn't be totalmalloc?

[adr]

On Tue, 28 Jun 2022, Dan Cross wrote:

[...]
void*
_threadmalloc(long size, int z)
{
  void *m;

  m = malloc(size);
  if (m == nil)
  sysfatal("Malloc of size %ld failed: %r", size);
  setmalloctag(m, getcallerpc());
  totalmalloc += size;
  if (size > 1) {
  fprint(2, "Malloc of size %ld, total %ld\n", size,
totalmalloc);
  abort();
  }
  if (z)
  memset(m, 0, size);
  return m;
}
[...]

Shouldn't the if statement test the size of totalmalloc before the
abort? That size, 100M for internal allocations? It has to be
totalmalloc, doesn't it? If not this if statement should be after
testing the success of the malloc. Am I missing something?


Note that the `if` statement doesn't test the size of *totalmalloc*, but
just `size`.  `totalsize` is only incidentally printed in the output if `size`
exceeds 100 MB: that is, if a single allocation is larger than 100MB.


I know, what called my attention is that size wasn't tested before
calling malloc, so the first thought I had was that the code had
a typo and it should be testing totalmalloc instead.


I mean, I think using libthread more like using small channels and thread's 
stack sizes, but:

Why put a limit here to size when totalmalloc could continue to grow until 
malloc fails?

If we want a limit, why don't we take into account the system resources?

If we want a constant limit, why don't we put it on threadimpl.h, explain why 
this value in a comment
and document it in thread(2)?

Why bother to call malloc before testing if size exeeds that limit???


Given the name of the function (`_threadmalloc`), I'd guess that this isn't
intended for general use, but rather, for the internal consumption of the
thread library, where indeed such a large allocation would likely be an
error (bear in mind this code was developed on 32-bit machines with RAMs
measured in Megabytes, not Gigabytes).


No, it's used also when creating a channel and setting a thread's
stack size.

adr

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te1be8dc72738258d-Mcbc484781129f693c26365ef
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: _threadmalloc() size>100000000; shouldn't be totalmalloc?

[adr]

On Sun, 26 Jun 2022, adr wrote:


Date: Sun, 26 Jun 2022 09:50:19 + (UTC)
From: adr 
To: 9fans@9fans.net
Subject: _threadmalloc() size>1; shouldn't be totalmalloc?

/sys/src/libthread/lib.c

[...]
void*
_threadmalloc(long size, int z)
{
  void *m;

  m = malloc(size);
  if (m == nil)
  sysfatal("Malloc of size %ld failed: %r", size);
  setmalloctag(m, getcallerpc());
  totalmalloc += size;
  if (size > 1) {
  fprint(2, "Malloc of size %ld, total %ld\n", size, 
totalmalloc);

  abort();
  }
  if (z)
  memset(m, 0, size);
  return m;
}
[...]

Shouldn't the if statement test the size of totalmalloc before the
abort? That size, 100M for internal allocations? It has to be
totalmalloc, doesn't it? If not this if statement should be after
testing the success of the malloc. Am I missing something?

adr.



I mean, I think using libthread more like using small channels and thread's 
stack sizes, but:

Why put a limit here to size when totalmalloc could continue to grow until 
malloc fails?

If we want a limit, why don't we take into account the system resources?

If we want a constant limit, why don't we put it on threadimpl.h, explain why 
this value in a comment
and document it in thread(2)?

Why bother to call malloc before testing if size exeeds that limit???

adr

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te1be8dc72738258d-Mf7cdc7010affd696392c0b47
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Tue, 28 Jun 2022, andrey100100...@gmail.com wrote:

Thanks for the patch.


It's just to play with it, note that onnote should be just passed
once.  I'll post another patch if things work ok.

adr

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M348ddb20db1a1bf17ce2b189
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] LPAE patch for ARM

[adr]

On Sat, 4 Jun 2022, Richard Miller wrote:

There's a new patch bcm-lpae which uses the 64-bit page table format to
allow 32-bit ARM kernels to support more than 4GB of physical memory. At
present this is mainly of interest for the 8GB Raspberry Pi 4, but there's
nothing Pi-specific in the MMU code so it may have future application for
bigger ARM systems.


Thanks a lot Richard!

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2b3e951db9f7c17f-Mc302193000a78af072a244de
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] atoi(s) != (int)strtol(s, nil, 10)

[adr]

I almost went nuts trying to figure out an estrange behavior of
neatroff. It's a 5c bug? It's using some GCC extension? No, it's
just that atoi is reading 08 as octal.

I sow some small discussion on the archives, so I'm not doing that
again, just an advise to new people porting software:

Grep for ato(i|l) first!

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfd15e5d5411bde5a-M6ce63c344a72d5488ffefe9c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Conversion of constants in C compiler

[adr]

Building cmd I noticed that the case of sizeof(int) = sizeof(long)
(which is the case in all compilers) wasn't managed with my changes.
I wonder if this logic mess could be shortened without making
impossible to read the 'if' conditions without throwing up (I've
tried).

I've compiled on arm the libraries, cmd and kernel (except ape)
without any problem.

adr.

/sys/src/cmd/cc/lex.c
[...]
   vv = yylval.vval;
   if(c1 & Numvlong ||
 (uvlong)convvtox(vv, TUVLONG) > convvtox(vv, TULONG)){
   /* unsigned suffix or hex occupying the sing bit */
   if((c1 & Numuns) || convvtox(vv, TVLONG) < 0 && (c1 & Numdec) == 
0) {
   c = LUVLCONST;
   t = TUVLONG;
   goto nret;
   }
   c = LVLCONST;
   t = TVLONG;
   goto nret;
   }
   if(c1 & Numlong ||
 (uvlong)convvtox(vv, TULONG) > convvtox(vv, TUINT)){
   if((c1 & Numuns) || convvtox(vv, TLONG) < 0 && (c1 & Numdec) == 
0) {
   c = LULCONST;
   t = TULONG;
   goto nret;
   }
   /* decimal occupying the sing bit */
   if(convvtox(vv, TLONG) < 0 && (c1 & Numdec)) {
   c = LVLCONST;
   t = TVLONG;
   goto nret;
   }
   c = LLCONST;
   t = TLONG;
   goto nret;
   }
   if((c1 & Numuns) || convvtox(vv, TINT) < 0 && (c1 & Numdec) == 0) {
   c = LUCONST;
   t = TUINT;
   goto nret;
   }
   if(convvtox(vv, TINT) < 0 && (c1 & Numdec)) {
   /* size(int) = size(long) */
   if(convvtox(vv, TLONG) < 0) {
   c = LVLCONST;
   t = TVLONG;
   goto nret;
   }
   c = LLCONST;
   t = TLONG;
   goto nret;
   }
   c = LCONST;
   t = TINT;
   goto nret;
[...]


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4bced580971a40a2-Mda3d0c619c734bb0e1cf708c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

Oh man... how silly, I know what's going on. We are using processes
not threads, so although we are sharing the same array of handlers,
they are registered for different processes. When the array is full
the next processes fail to register handlers _for_them_ so as andrey
rightly said, the default action (death) is taken when the alarm
note is sent.

The solution is obvious, cancel the process' handlers before it
exits so we don't run out of space.

Now, is there any reason to not do that in threadexits() when it
terminates the process?

Shouldn't threadnotify() cancel only the process' handlers? We are
sharing onnote[NFN] and the code as it is right now removes the
first handler that match the pointer, it can belong to another
process.

Something like this?:

int
threadnotify(int (*f)(void*, char*), int in)
{
   int i, topid;
   int (*from)(void*, char*), (*to)(void*, char*);

   if(in){
   from = nil;
   frompid = 0;
   to = f;
   topid = _threadgetproc()->pid;
   }else{
   from = f;
   frompid = _threadgetproc()->pid;
   to = nil;
   topid = 0;
   }
   lock();
   for(i=0; ihttps://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M45b18058b8188bfcc376c11c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Sun, 19 Jun 2022, adr wrote:

The solution is obvious, cancel the process' handlers before it
exits so we don't run out of space.


This was really silly...


Now, is there any reason to not do that in threadexits() when it
terminates the process?

Shouldn't threadnotify() cancel only the process' handlers? We are
sharing onnote[NFN] and the code as it is right now removes the
first handler that match the pointer, it can belong to another
process.


I ended up playing with this (do not register duplicated handlers,
cancel only the notes of the thread's process and cancel all notes
when the process exits):

/sys/src/libthread/sched.c:
[...]
   if(t == nil){
   _threaddebug(DBGSCHED, "all threads gone; exiting");
   cancelnotes(p->pid);
   _schedexit(p);
   }
[...]
/sys/src/libthread/note.c
[...]
int
threadnotify(int (*f)(void*, char*), int in)
{
   int i, frompid, topid;
   int (*from)(void*, char*), (*to)(void*, char*);

   if(in){
   from = nil;
   frompid = 0;
   to = f;
   topid = _threadgetproc()->pid;
   lock();
   for(i=0; ipid;
   to = nil;
   topid = 0;
   }
   lock();
   for(i=0; ihttps://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M2ce0715ee9e683875392de68
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Fri, 17 Jun 2022, Skip Tavakkolian wrote:

Thanks to Douglas Adams, I think '42' might be a more obvious magic
number for a clue:

% 8c udpflood.c && 8l -o udpflood udpflood.8 && ./udpflood | grep end | wc -l
42
% grep 42 /sys/src/libthread/note.c
#define NFN 42


I don't understand, why does it work when commenting out the read
statement? Why it doesn't work even removing all the notification
handling?  Maybe I have it all wrong, but I think there is more to
this.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M346082debc6a2d5b01267879
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Fri, 17 Jun 2022, andrey100100...@gmail.com wrote:

Seems like noted() call not needed in user code.


noted() is only needed when using the syscall notify, when using
atnotify() (or threadnotify) you don't need it, as it is said in
notify(2) and you did correctly in your first example. threadnotify
doesn't kill your process if there is no space free in onnote[],
onnotepid[], the handler is not registered, that's all. alarm()
should send the note to the process and the first handler registered
with the note "alarm" should be executed. Your handler checked for
the note and returned non zero, the process should continue. When
read is interrupted, it should return an error, the process should
not be killed. Here is the issue. Comment the read statement and
there will be the same number of "end"s as "start"s.

Note that you could register the handler in threadmain and avoid
completely this issue, but as I said before, something seems wrong
to me here.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Madcf140195c52ad821869376
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Sat, 18 Jun 2022, adr wrote:


On Sat, 18 Jun 2022, andrey100100...@gmail.com wrote:


-

cpu% 6.out | grep end | wc -l
33


Problem in unregistered handlers.


But unregistered handlers shouldn't be a problem. The process is
been killed when alarm sends the note. That's why the code worked
removing the read statement, the alarm is set off and the note is
not sent before the process ends. I just don't see why the process
is been killed. The documentation describes another behavior. To
me it smells like bug barbecue (corrupted onnote?). Maybe I got
something wrong, bear with me.


Note that you could register the handler in threadmain and avoid
completely this issue, but as I said before, something seems wrong
to me here.


I'm don't understand how handler in threadmain would solve the problem.
I need in 'alarm' on per process basis.


You need alarm() in every process, but you don't need to register the
same handler 80 times!

adr.


I think there is some confussion here, so I'll explain myself a
little more.

Lets change your last example to not use libthread:

#include 
#include 

int
handler_alarm(void *, char *msg)
{
if(strstr(msg, "alarm")){
return 1;
}

return 0;
}

int
test(void)
{
if(atnotify(handler_alarm, 1) == 0){
fprint(1, "handler not registered\n");
}

alarm(10);
fprint(1, "start\n");
sleep(40);
fprint(1, "end\n");
alarm(0);

return 0;
}

void
main()
{
for(int i = 0; i < 80; i++){
test();
}

exits(nil);
}

You see, after the NFNth iteration of test(), onnot[NFN] in atnotify
will be full, the handlers wont be registered but the code will
work without any problem. It doesn't matter, the first handler in
onnot[] will be executed. I fact you only need one handler there, not
80, you should move atnotify to main.

The same should be happening with libthread. I'm really the only
one smelling a bug here?

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M47714addb2d648e020737917
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Sat, 18 Jun 2022, andrey100100...@gmail.com wrote:


-

cpu% 6.out | grep end | wc -l
33


Problem in unregistered handlers.


But unregistered handlers shouldn't be a problem. The process is
been killed when alarm sends the note. That's why the code worked
removing the read statement, the alarm is set off and the note is
not sent before the process ends. I just don't see why the process
is been killed. The documentation describes another behaivor. To
me it smells like bug barbecue (corrupted onnote?). Maybe I got
something wrong, bear with me.


Note that you could register the handler in threadmain and avoid
completely this issue, but as I said before, something seems wrong
to me here.


I'm don't understand how handler in threadmain would solve the problem.
I need in 'alarm' on per process basis.


You need alarm() in every process, but you don't need to register the
same handler 80 times!

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M62a1f2e8578fcd812c35b4b5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Sat, 18 Jun 2022, Jacob Moody wrote:

I've attempted to reproduce it, trying to remove the libthread/notify
factors. I've come up with this:

#include 
#include 

static void
proc_udp(void*)
{
   char resp[512];
   char req[] = "request";
   int fd;
   int n;
   int pid;

   fd = dial("udp!185.157.221.201!5678", nil, nil, nil);
   if(fd < 0)
   exits("can't dial");

   if(write(fd, req, strlen(req)) != strlen(req))
   exits("can't write");

   pid = getpid();
   fprint(1, "start %d\n", pid);
   n = read(fd, resp, sizeof(resp)-1);
   fprint(1, "end %d %d\n", pid, n);
   exits(nil);
}

void
main(int, char**)
{
   int i;
   Waitmsg *wm;

   for(i = 0; i < 10; i++){
   switch(fork()){
   case -1:
   sysfatal("fork %r");
   case 0:
   proc_udp(nil);
   sysfatal("ret");
   default:
   break;
   }
   }
   for(i = 0; i < 10; i++){
   wm = wait();
   print("proc %d died with message %s\n", wm->pid, wm->msg);
   }
   exits(nil);
}

This code makes it pretty obvious that we are losing some children;
on my machine this program never exits. I see some portion of the
readers correctly returning -1, and the parent is able to get their
Waitmsg but not all of them.


Moody I think this old thread will interest you:

https://marc.info/?t=11273092041=1=2

Russ Cox explained there:
 It appears that your program, at its core, it is doing this:

 void
 readproc(void *v)
 {
 int fd;
 char buf[100];
 fd = (int)v;
 read(fd, buf, sizeof buf);
 }

 void
 threadmain(int argc, char **argv)
 {
 int p[2];
 pipe(p);
 proccreate(readproc, (void*)p[0], 8192);
 proccreate(readproc, (void*)p[1], 8192);
 close(p[0]);
 /* and here you expect the first readproc to be done */
 close(p[1]);
 /* and here the second */
 }

 Each read call is holding up a reference to its channel
 inside the kernel, so that even though you've closed the fd
 and removed the ref from the fd table, there is still a reference
 to each side of the pipe in the form of the process blocked
 on the read.

 I've never been sure whether the implicit ref held during
 the system call is good behavior, but it's hard to change.

 In your case, writing 0 (or anything) makes the read
 finish, releasing the last ref to the underlying pipe when
 the system call finishes, and then everything cleans up
 as expected.  So you've found your workaround, and now
 we understand why it works.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M6e48031f9e8673387c0b47b8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Sun, 19 Jun 2022, andrey100100...@gmail.com wrote:

No way. All processes must run simultaneously.
NFN limit cannot be bypassed.


Yeah, that's why I said it was silly:

The solution is obvious, cancel the process' handlers before it
exits so we don't run out of space.


This was really silly...


The changes I'm testing are not for evading the limit, but for
making the handler managment more efficient and specially to avoid
the case when a process could remove another process' handler from
onnote[].

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M4d8837da259920e0095176e2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Mon, 20 Jun 2022, adr wrote:

But I have something in mind for a case like
this, when all the processes are going to use the same handler
(that's why I was asking). Let me play with it a litle before I
share it.


Ok, the idea is this: If in is bigger than zero in
threadnotify(int (*f)(void*, char*), int in), the handler is register
for the calling process. If in is 0, then the handler is cleared
for the calling process. If in is -1, the handler is register for
all processes and if in is less than -1, it is cleared for all
processes (expect for those who have already registered it for themselves).

Now back to your example, as all the processes are going to use the same 
handler,
you just have to register it once in threadmain:

#include  
#include  
#include 


static int
handler_alarm(void *, char *msg)
{
   if(strstr(msg, "alarm"))
   return 1;
   return 0;
}

static void
proc_udp(void *)
{
   char resp[512];
   char req[] = "request";
   int fd;
   if((fd = dial("udp!185.157.221.201!5678", nil, nil, nil)) >= 0){
   if(write(fd, req, strlen(req)) == strlen(req)){
   fprint(1, "start\n");
   alarm(2000);
   read(fd, resp, sizeof(resp));
   alarm(0);
   fprint(1, "end\n");
   }
   close(fd);
   }
   threadexits(nil);
}

int mainstacksize = 5242880;

void
threadmain(int argc, char *argv[])
{
   threadnotify(handler_alarm, -1);
   for(int i = 0; i < 80; i++)
   proccreate(proc_udp, nil, 10240);
   sleep(5000);
   threadexitsall(nil);
}
Now,
; ./5.out | grep end | wc -l
 80

Are you happy Andrej?

adr.

/sys/src/libthread/sched.c: 
[...]

   if(t == nil){
   _threaddebug(DBGSCHED, "all threads gone; exiting");
   cancelnotes(p->pid);
   _schedexit(p);
   } 
[...] 
/sys/src/libthread/note.c 
[...] 
int 
threadnotify(int (*f)(void*, char*), int in) 
{

   int i, frompid, topid;
   int (*from)(void*, char*), (*to)(void*, char*);

   if(in && in>-2){
   from = nil;
   frompid = 0;
   to = f;
   topid = (in == -1)? -1 : _threadgetproc()->pid;
   lock();
   for(i=0; ipid;
   to = nil;
   topid = 0;
   }
   lock();
   for(i=0; ipending)
   return;

   p->pending = 0;
   for(n=notes; nproc == p){
   for(i=0; ipid && onnotepid[i]!=-1) || 
(fn = onnote[i])==nil)
   continue;
   if((*fn)(v, n->s))
   break;
[...]
/sys/include/thread.h 
[...] 
void cancelnotes(int pid); 
[...] 


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Meda7cacd5cce9cc74c1ddaf8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Mon, 20 Jun 2022, andrey100100...@gmail.com wrote:

The note 'alarm' is needed to interrupt the system call on timeout
since system calls to lan 9 can be of a network nature, a notes is
indispensable.
A great example of this is the read() system call on a udp-connection.
How else can this system call be interrupted?


Start two processes, one which just make the call, another as a
timer to kill it. But I have something in mind for a case like
this, when all the processes are going to use the same handler
(that's why I was asking). Let me play with it a litle before I
share it.

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Mc017bb6a54415db715338ff2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes (fwd)

[adr]

The last mail got screwed, I'm resending this for clarity. 
/sys/src/libthread/sched.c:

[...]
   if(t == nil){
   _threaddebug(DBGSCHED, "all threads gone; exiting");
   cancelnotes(p->pid);
   _schedexit(p);
   }
[...] 
/sys/src/libthread/note.c

[...]
int
threadnotify(int (*f)(void*, char*), int in)
{
   int i, frompid, topid;
   int (*from)(void*, char*), (*to)(void*, char*);

   if(in && in>-2){
   from = nil;
   frompid = 0;
   to = f;
   topid = (in == -1)? -1 : _threadgetproc()->pid;
   lock();
   for(i=0; ipid;
   to = nil;
   topid = 0;
   }
   lock();
   for(i=0; ipending)
   return;

   p->pending = 0;
   for(n=notes; nproc == p){
   for(i=0; ipid && onnotepid[i]!=-1) || 
(fn = onnote[i])==nil)
   continue;
   if((*fn)(v, n->s))
   break;
[...]
/sys/include/thread.h
[...]
void cancelnotes(int pid);
[...] 


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5a58cfad5bc60d5c-Mcbab164c50af064e722c9315
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Mon, 20 Jun 2022, Skip Tavakkolian wrote:

It's cleaner to use channels with separate io and timer threads that
do their syscalls via ioproc; this one doesn't require any changes to libthread:

https://gist.github.com/9nut/aaa9b9b6a22d69996b75ccdc6e615c61


Nice example, but I strongly recomend changing libthread or removing
notes support. Right now:

If a process try to remove a handler which has been register for
another process before, it will remove the handler for that process
instead of its own.

When a process exits its handlers are not cleared, so if the process
doesn't call threadnotify to clean its handlers, this space is
wasted for the rest of the program. Also it makes sense to clean
them all at exit instead of doing it explicity for each handler.

threadnotify will insert duplicated handlers, wasting the limited
space in onnote[], onnotepid[]. Note that those duplicated handlers
will be completly ignored, they will just occupy space.

If you are using notes and all your processes are going to share
the same array of handlers, doesn't make sense to be able to register
handlers which could be used by all of them?

Another discussion is if the notes mechanism really fits in libthread,
as I said, maybe is better to remove notes support completly and
force the programmer to exploit the api. Yours is a good example.

Regards,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Mc9df1d1014565db0ee016754
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Tue, 21 Jun 2022, andrey100100...@gmail.com wrote:

? ??, 20/06/2022 ? 15:29 -0700, Skip Tavakkolian ?:

It's cleaner to use channels with separate io and timer threads that
do their syscalls via ioproc; this one doesn't require any changes to
libthread:

https://gist.github.com/9nut/aaa9b9b6a22d69996b75ccdc6e615c61


Thanks for the work you've done!
Yes, I have considered this possibility.
But it was precisely this kind of code bloat that I wanted to avoid.


It looks like code bloat, but it really isn't. It is doing the job
with the tools of the api according to the paradigm designed in
libthread. That's why the word "cleaner" is completely correct.

I think note.c was added to resolve some particual case, and for
the state of note.c, I don't think it has been used too much.

For example, let's remove note.c. You could obtain the same result
in your example (all processes using the same handler) using atnotify
because the notes are registered to the children when proccreate
uses rfork:

void
threadmain(int argc, char *argv[])
{
   atnotify(handler_alarm, 1);

./5.out | grep end | wc -l
   80

If you have to use a different handler for each processes you can't
use atnotify because of RFMEM, but you can use the syscalls notify
and noted:

#include  
#include  
#include 


static void
handler_alarm(void *, char *msg)
{
   if(strstr(msg, "alarm")){
   print("yes");
   noted(NCONT);
   return; /* just in case */
   }
   noted(NDFLT);
}

static void
proc_udp(void *)
{
   char resp[512];
   char req[] = "request";
   int fd;
   notify(handler_alarm);
   if((fd = dial("udp!185.157.221.201!5678", nil, nil, nil)) >= 0){
   if(write(fd, req, strlen(req)) == strlen(req)){
   fprint(1, "start\n");
   alarm(2000);
   read(fd, resp, sizeof(resp));
   alarm(0);
   fprint(1, "end\n");
   }
   close(fd);
   }
   threadexits(nil);
}

int mainstacksize = 5242880;

void
threadmain(int argc, char *argv[])
{
   for(int i = 0; i < 80; i++)
   proccreate(proc_udp, nil, 10240);
   sleep(5000);
   threadexitsall(nil);
 }

./5.out | grep end | wc -l
   80

Threadnotify is trying to do an atnotify that works with RFMEM,
but to do that onnote should be allocated to grow or shrink (or
have a size thinking in the maximum number of processes the program
could spawn, not the number of handlers a process could register
as in atnotify), instead of pointers to handlers, it should be an
array of pointers to arrays of handlers allocated by each process.

Now again, does the notes mechanism actually fit in libthread? If
it does it should be fixed, if not removed.

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Mf12e91abda54e653de320337
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Sun, 19 Jun 2022, andrey100100...@gmail.com wrote:

Yes, you were absolutely right, the thread library needs some work.

It is impossible to use multiple processes with notes, due to the
exhaustion of the NFN limit.


Andrej, what are you going to do with alarm in the real thing?

You could use threads (cooperative round-ribbon multitasking) using
some data log to register their state and use a "master" thread to
control them (kill them, change some data structure, etc).

You can use rfork, locks, pipes, etc and forget about libthread.

You could experiment with the topology of the nodes, for example
instead of a big star you can simplify things a lot using chains
of nodes where the last node sends the chain data to the analyzer
(you were talking about polling sensors):

aNode1 --> aNode2 --> aNode3 --> ... --> aNoden -->
  
> --- > Anz
bNode1 --> bNode2 --> bNode3 --> ... --> bNoden -->

Imagine that n=100. Each node only has to make a connection with
2 nodes (the first of the chain just one), adding data to the
received one and send it to the next. Anz only has to make a
connection with the last nodes of the chains, two in this case,
and process the data received. Of course you have to play with your
numbers, the acceptable delay, etc.

I'm pretty sure people here could point you to some examples using
plan9, and note that you could use raspberry pi zeros as nodes.

Have fun.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Md1b869bf61deccadf9733908
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Tue, 21 Jun 2022, andrey100100...@gmail.com wrote:


For example, let's remove note.c. You could obtain the same result


Just for clarity, you actually don't need to remove note.c to do
what I said below.


in your example (all processes using the same handler) using atnotify
because the notes are registered to the children when proccreate
uses rfork:

void
threadmain(int argc, char *argv[])
{
atnotify(handler_alarm, 1);

./5.out | grep end | wc -l
80

If you have to use a different handler for each processes you can't
use atnotify because of RFMEM, but you can use the syscalls notify
and noted:

#include 
#include 
#include 

static void
handler_alarm(void *, char *msg)
{
if(strstr(msg, "alarm")){
print("yes");
noted(NCONT);
return; /* just in case */
}
noted(NDFLT);
}

static void
proc_udp(void *)
{
char resp[512];
char req[] = "request";
int fd;
notify(handler_alarm);
if((fd = dial("udp!185.157.221.201!5678", nil, nil, nil)) >=
0){
if(write(fd, req, strlen(req)) == strlen(req)){
fprint(1, "start\n");
alarm(2000);
read(fd, resp, sizeof(resp));
alarm(0);
fprint(1, "end\n");
}
close(fd);
}
threadexits(nil);
}

int mainstacksize = 5242880;

void
threadmain(int argc, char *argv[])
{
for(int i = 0; i < 80; i++)
proccreate(proc_udp, nil, 10240);
sleep(5000);
threadexitsall(nil);
  }

./5.out | grep end | wc -l
80

Threadnotify is trying to do an atnotify that works with RFMEM,
but to do that onnote should be allocated to grow or shrink (or
have a size thinking in the maximum number of processes the program
could spawn, not the number of handlers a process could register
as in atnotify), instead of pointers to handlers, it should be an
array of pointers to arrays of handlers allocated by each process.

Now again, does the notes mechanism actually fit in libthread? If
it does it should be fixed, if not removed.



I vote for the fix.
Perhaps the notification is being used somewhere or by someone.




adr.



Regards,
Andrej


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M198ebde18601eb82a1a5b8d8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[adr]

On Sat, 21 May 2022, Dan Cross wrote:

To answer your original question, no: there is no aarch64 support in either 
9legacy or the
Bell Labs distribution.

- Dan C.


I just ported 7c, 7l and 7a from 9front. I'm adjusting libmach,
mkfiles, etc. Porting 9front's aarch64 raspberry pi kernel can be
an oportunity to learn about the kernel design.

adr.

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

[9fans] Re: bind netdev: unknown interface type

[adr]

On Sun, 17 Jul 2022, adr wrote:

Hi,
Experimenting with netdev, I got:

foo:
#!/bin/rc
<> /net/ipifc/clone {
  echo bind netdev /tmp/1>[1=0]
}

; foo
echo: write error: unknown interface type

I really would appreciate some hint!

adr.


Oh, I see, netdevmedium is not in the rpi4 kernel configuration file.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T769e45db306d29b7-M8802e2371ff2fb715a15c866
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] bind netdev: unknown interface type

[adr]

Hi,
Experimenting with netdev, I got:

foo:
#!/bin/rc
<> /net/ipifc/clone {
   echo bind netdev /tmp/1>[1=0]
}

; foo
echo: write error: unknown interface type

I really would appreciate some hint!

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T769e45db306d29b7-Me76d9c3a3b0422a582dd7e99
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: ctrans - Chinese language input for Plan9

[adr]

> I stumbled onto an instructive video on youtube not that long ago. I'm
> sure there are a few you'll be able to search for. If I understand
> correctly, it's a combination of entering the phoneme by the nearest
> Latin letter, then select from a diminishing range of suitable options
> on the screen.

There are other input methods based on the shape of the characters. Some are 
better with traditional Chinese characters, other with simplified characters, 
it's complicated... Let see if some Chinese comrade share with us his daily 
life experience. The Japanese is input writing kana directly with a Japanese 
keyboard or by romaji with roman characters on western keyboards (ka -> か, ) 
and then transformed to kanji when necessary. There are different IMEs, but the 
principle is the same. I suppose that ktrans is similar, I haven't tried jet.

adr
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tba6835d445e07919-M428fc6fd31a9ffdb29d773bc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: ctrans - Chinese language input for Plan9

[adr]

> I know that the russian tech was very
> isolated compared to modern technology.

The most interesting for me are the Setun ternary computers designed by Nikolay 
Brusentsov in the late '50s running a Forth like system. They did a lot of 
research and came to the conclusion that Forth was _the_ language. They saw 
Forth as a discovery by Chuck Moore, not an invention (to give him more credit, 
no less). The binary computers that become popular (m-3, ural, etc) were slowly 
replaced by clones of western computers PDP-11, Intel, Vax, etc). The operating 
systems were mostly clones too. The computers of the '80s and '90s in schools 
and homes were clones of PC, Apple, Z80. The Spectrum clones were very popular. 
Asian computer technology was imported from the Western or Soviet worlds, so 
they had to add devices or methods to enter their own characters (look for some 
crazy keyboard built in Taiwan). The early input methods (form the '70s?) were 
pretty much like the ones we use today. As far as I know, there wasn't any 
Asian computer created without Western or Soviet influence.

adr
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tba6835d445e07919-Mfe79a57631b9a0b4b7b839e8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: ctrans - Chinese language input for Plan9

[adr]

> Silvan Jegen wrote:
> ktrans seems to be quite different actually. According to the
> documentation it uses the Cangjie input method
I was really surprised when I read this and of course, this is not true. I 
suppose you meant ctrans.

https://git.sansfontieres.com/~romi/ktrans/tree/front/item/README.kenji

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tba6835d445e07919-M0049de1a1058af72e04fe22c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: ctrans - Chinese language input for Plan9

[adr]

Yep, Cangjie is one of those input methods based on shape I was talking about, 
more appropriate for traditional Chinese characters used in Taiwan, Hong-Kong, 
etc. South Korea still use kanji similar to traditional Chinese, but I don't 
know what input method they use. Note that in mainland China people use Pinyin 
because they imposed the use of simplified Chinese characters.  It surprises me 
to hear that ktrans uses Cangjie, Japanese keyboards let you input kana 
directly, and the use of kana to write without kanji is common, specially in 
books for kids, so it seams more natural to me to make a kana->kanji conversion 
(or romaji->kana->kanji in Western keyboards). But I'm not Japanese, maybe 
Cangjie is faster, I've never tryed.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tba6835d445e07919-M9f10d9140a5f0838d615958f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[adr]

On Tue, 28 Jun 2022, adr wrote:


Andrey, if you want to use different note handlers per process (with a big
number of processes) using libthread, this may be helpful.

The idea is this:

An array of handlers for all processes which can be changed by all processes.
When a note is received by a process, this array takes priority.

An array of pointers to structures of the type

struct Onnote
{
  int pid;
  int (*fn[NFN])(void*, char*);
};

initially of size PPCHUNK (I set it to 100, experiment with that),
but it can grow if necessary (but not shrink, I think this would
be overkilling).

These structures are allocated the first time a process record a
handler and freed when the process exits (or by calling
threadcancelnotes(), note that this function can free other processes'
function handlers, maybe should be better to make some restrictions)

The use of "in" in threadnotify(int (*f)(void*, char*), int in) is:

in > 0 : set the handler for the calling process.
in == 0 : clear the handler for the calling process.
in == -1 : clear the handler for all processes (except those who has
  registered it already for themselves).
in < -1 : set the handler for all processes.

There is no use of threadnotify with "in < 0" in /sys/src, so nothing is 
broken.


As you are using 9front and they are serving their sources with
9p, here is a diff to their sources. I haven't compiled it in
9front, though. Note that if you want to compile the system with
this changes, you have to eliminate the copy of note.c at
/sys/src/cmd/execnet (it seems that note.c was added afterwards as
I thought).

I haven't test it too much, this has been more like a time-destroyer
pastime.


This just evade going through the arrays twice. For the current
value of NFN it doesn't make too much a difference, note that this
structures are locked. It just was hurting my eyes.
--- /tmp/main.c
+++ /sys/src/libthread/main.c
@@ -28,6 +28,10 @@
   _qlockinit(_threadrendezvous);
   _sysfatal = _threadsysfatal;
   __assert = _threadassert;
+   onnote = mallocz(PPCHUNK*sizeof(uintptr), 1);
+   if(!onnote)
+   sysfatal("Malloc of size %d failed: %r", 
PPCHUNK*sizeof(uintptr));
+   onnotesize = PPCHUNK;
   notify(_threadnote);
   if(mainstacksize == 0)
   mainstacksize = 8*1024;
--- /tmp/note.c
+++ /sys/src/libthread/note.c
@@ -5,7 +5,6 @@

 int   _threadnopasser;

-#defineNFN 33
 #define   ERRLEN  48
 typedef struct Note Note;
 struct Note
@@ -17,62 +16,161 @@

 static Note   notes[128];
 static Note   *enotes = notes+nelem(notes);
-static int (*onnote[NFN])(void*, char*);
-static int onnotepid[NFN];
+Onnote **onnote;
+int onnotesize;
+static int (*onnoteall[NFN])(void*, char*);
 static Lock   onnotelock;

 int
 threadnotify(int (*f)(void*, char*), int in)
 {
-   int i, topid;
-   int (*from)(void*, char*), (*to)(void*, char*);
+   int i, j, n;

-   if(in){
-   from = nil;
-   to = f;
-   topid = _threadgetproc()->pid;
-   }else{
-   from = f;
-   to = nil;
-   topid = 0;
-   }
   lock();
-   for(i=0; i -1)
+   onnoteall[n] = f;
+   unlock();
+   return n>-1;
+   }
+
+   /* remove note for all processes */
+   if(in == -1){
+   for(i=0; ipid==_threadgetproc()->pid){
+   for(j=0; jfn[j] == f){
+   onnote[i]->fn[j] = 0;
+   break;
+   }
+   }
+   unlock();
+   return jpid==_threadgetproc()->pid)
+   break;
+
+   /* process has already a slot */
+   if(i < onnotesize){
+   n = -1;
+   for(j=0; jfn[j] == f){
+   unlock();
+   return 1;
+   }
+   if(onnote[i]->fn[j] == nil)
+   n = j;
+   }
+   if(n > -1)
+   onnote[i]->fn[n] = f;
+   unlock();
+   return n>-1;
+ 
+   }

+
+   for(i=0; ipid = _threadgetproc()->pid;
+   onnote[i]->fn[0] = f;
+   unlock();
+   return 1;
+}
+
+void
+threadcancelnotes(int pid)
+{
+   int i;
+
+   lock();
+   for(i=0; ipid==pid){
+   free(onnote[i]);
+   onnote[i] = nil;
   break;
   }
   unlock();
-   return ipending)
   return;

   p->pending = 0;
+   all = j = 0;
   for(n=notes; nproc == p){
-   strcpy(s, n->s);
-   n->p

Re: [9fans] syscall silently kill processes

[adr]

On Tue, 28 Jun 2022, adr wrote:

This just evade going through the arrays twice. For the current
value of NFN it doesn't make too much a difference, note that this
structures are locked. It just was hurting my eyes.


Sorry for the noise, bad patch.
--- /tmp/main.c
+++ /sys/src/libthread/main.c
@@ -28,6 +28,10 @@
   _qlockinit(_threadrendezvous);
   _sysfatal = _threadsysfatal;
   __assert = _threadassert;
+   onnote = mallocz(PPCHUNK*sizeof(uintptr), 1);
+   if(!onnote)
+   sysfatal("Malloc of size %d failed: %r", 
PPCHUNK*sizeof(uintptr));
+   onnotesize = PPCHUNK;
   notify(_threadnote);
   if(mainstacksize == 0)
   mainstacksize = 8*1024;
--- /tmp/note.c
+++ /sys/src/libthread/note.c
@@ -5,7 +5,6 @@

 int   _threadnopasser;

-#defineNFN 33
 #define   ERRLEN  48
 typedef struct Note Note;
 struct Note
@@ -17,62 +16,161 @@

 static Note   notes[128];
 static Note   *enotes = notes+nelem(notes);
-static int (*onnote[NFN])(void*, char*);
-static int onnotepid[NFN];
+Onnote **onnote;
+int onnotesize;
+static int (*onnoteall[NFN])(void*, char*);
 static Lock   onnotelock;

 int
 threadnotify(int (*f)(void*, char*), int in)
 {
-   int i, topid;
-   int (*from)(void*, char*), (*to)(void*, char*);
+   int i, j, n;

-   if(in){
-   from = nil;
-   to = f;
-   topid = _threadgetproc()->pid;
-   }else{
-   from = f;
-   to = nil;
-   topid = 0;
-   }
   lock();
-   for(i=0; i -1)
+   onnoteall[n] = f;
+   unlock();
+   return n>-1;
+   }
+
+   /* remove note for all processes */
+   if(in == -1){
+   for(i=0; ipid==_threadgetproc()->pid){
+   for(j=0; jfn[j] == f){
+   onnote[i]->fn[j] = 0;
+   break;
+   }
+   }
+   unlock();
+   return jpid==_threadgetproc()->pid)
+   break;
+
+   /* process has already a slot */
+   if(i < onnotesize){
+   n = -1;
+   for(j=0; jfn[j] == f){
+   unlock();
+   return 1;
+   }
+   if(onnote[i]->fn[j]==nil && n==-1)
+   n = j;
+   }
+   if(n > -1)
+   onnote[i]->fn[n] = f;
+   unlock();
+   return n>-1;
+ 
+   }

+
+   for(i=0; ipid = _threadgetproc()->pid;
+   onnote[i]->fn[0] = f;
+   unlock();
+   return 1;
+}
+
+void
+threadcancelnotes(int pid)
+{
+   int i;
+
+   lock();
+   for(i=0; ipid==pid){
+   free(onnote[i]);
+   onnote[i] = nil;
   break;
   }
   unlock();
-   return ipending)
   return;

   p->pending = 0;
+   all = j = 0;
   for(n=notes; nproc == p){
-   strcpy(s, n->s);
-   n->proc = nil;
-   unlock(>inuse);
-
-   for(i=0; ipid || (fn = 
onnote[i])==nil)
-   continue;
-   if((*fn)(v, s))
-   break;
+   for(i=0; is)){
+   all = 1;
+   break;
+   }
+   if(!all){
+   for(i=0; ipid==p->pid){
+   for(j=0; jfn[j])
+   if((*f)(v, 
n->s))
+   break;
+   break;
+   }
   }
-   if(i==NFN){
-   _threaddebug(DBGNOTE, "Unhandled note %s, proc 
%p", n->s, p);
+   if(!all && (i==onnotesize || j==NFN)){
+   _threaddebug(DBGNOTE, "Unhandled note %s, proc 
%p\n", n->s, p);
   if(v != nil)
   noted(NDFLT);
   else if(strncmp(n->s, "sys:", 4)==0)
@@ -79,6 +177,8 @@
   abort();
   threadexitsall(n->s);
   }
+   n->proc = nil;
+   

Re: [9fans] syscall silently kill processes

[adr]

Andrey, if you want to use different note handlers per process (with a big
number of processes) using libthread, this may be helpful.

The idea is this:

An array of handlers for all processes which can be changed by all processes.
When a note is received by a process, this array takes priority.

An array of pointers to structures of the type

struct Onnote
{
   int pid;
   int (*fn[NFN])(void*, char*);
};

initially of size PPCHUNK (I set it to 100, experiment with that),
but it can grow if necessary (but not shrink, I think this would
be overkilling).

These structures are allocated the first time a process record a
handler and freed when the process exits (or by calling
threadcancelnotes(), note that this function can free other processes'
function handlers, maybe should be better to make some restrictions)

The use of "in" in threadnotify(int (*f)(void*, char*), int in) is:

in > 0 : set the handler for the calling process.
in == 0 : clear the handler for the calling process.
in == -1 : clear the handler for all processes (except those who has
   registered it already for themselves).
in < -1 : set the handler for all processes.

There is no use of threadnotify with "in < 0" in /sys/src, so nothing is broken.

As you are using 9front and they are serving their sources with
9p, here is a diff to their sources. I haven't compiled it in
9front, though. Note that if you want to compile the system with
this changes, you have to eliminate the copy of note.c at
/sys/src/cmd/execnet (it seems that note.c was added afterwards as
I thought).

I haven't test it too much, this has been more like a time-destroyer
pastime.

adr
--- /tmp/main.c
+++ /sys/src/libthread/main.c
@@ -28,6 +28,10 @@
   _qlockinit(_threadrendezvous);
   _sysfatal = _threadsysfatal;
   __assert = _threadassert;
+   onnote = mallocz(PPCHUNK*sizeof(uintptr), 1);
+   if(!onnote)
+   sysfatal("Malloc of size %d failed: %r", 
PPCHUNK*sizeof(uintptr));
+   onnotesize = PPCHUNK;
   notify(_threadnote);
   if(mainstacksize == 0)
   mainstacksize = 8*1024;
--- /tmp/note.c
+++ /sys/src/libthread/note.c
@@ -5,9 +5,9 @@

 int   _threadnopasser;

-#defineNFN 33
 #define   ERRLEN  48
 typedef struct Note Note;
+
 struct Note
 {
   Lockinuse;
@@ -17,62 +17,155 @@

 static Note   notes[128];
 static Note   *enotes = notes+nelem(notes);
-static int (*onnote[NFN])(void*, char*);
-static int onnotepid[NFN];
+Onnote **onnote;
+int onnotesize;
+static int (*onnoteall[NFN])(void*, char*);
 static Lock   onnotelock;

 int
 threadnotify(int (*f)(void*, char*), int in)
 {
-   int i, topid;
-   int (*from)(void*, char*), (*to)(void*, char*);
+   int i, j;

-   if(in){
-   from = nil;
-   to = f;
-   topid = _threadgetproc()->pid;
-   }else{
-   from = f;
-   to = nil;
-   topid = 0;
-   }
   lock();
-   for(i=0; ipid==_threadgetproc()->pid){
+   for(j=0; jfn[j] == f){
+   onnote[i]->fn[j] = 0;
+   break;
+   }
+   }
+   unlock();
+   return jpid==_threadgetproc()->pid)
+   break;
+
+   /* process has already a slot */
+   if(i < onnotesize){
+   for(j=0; jfn[j] == nil){
+   onnote[i]->fn[j] = f;
+   break;
+   }
+   }
+   unlock();
+   return j+ 
+   }

+
+   for(i=0; ipid = _threadgetproc()->pid;
+   onnote[i]->fn[0] = f;
+   unlock();
+   return 1;
+}
+
+void
+threadcancelnotes(int pid)
+{
+   int i;
+
+   lock();
+   for(i=0; ipid==pid){
+   free(onnote[i]);
+   onnote[i] = nil;
   break;
   }
   unlock();
-   return ipending)
   return;

   p->pending = 0;
+   all = j = 0;
   for(n=notes; nproc == p){
-   strcpy(s, n->s);
-   n->proc = nil;
-   unlock(>inuse);
-
-   for(i=0; ipid || (fn = 
onnote[i])==nil)
-   continue;
-   if((*fn)(v, s))
-   break;
+   for(i=0; is)){
+   all = 1;
+   break;
+   }
+   if(!all){
+   for(i=0; ip

Re: [9fans] Re: _threadmalloc() size>100000000; shouldn't be totalmalloc?

[adr]

On Tue, 28 Jun 2022, Dan Cross wrote:

You mean by `newthread` and `chancreate`? Those are part of the
thread library. Notice that there are no callers outside of /sys/src/libthread.


What I mean is that "size" in _threadmalloc() will be set by those
functions with values directly given by the programmer, with this
limit not documented.

I wouldn't call a function wich is part of an api internal. An
internal function, for me, is a function inaccesible for the
programmer, like _threadmalloc itself.

By the way, you mean threadcreate, don't you?

Regars,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te1be8dc72738258d-M0c09e2ed1ced2383c89f1fe9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Conversion of constants in C compiler

[adr]

I think this gets the condition slightly wrong. For a decimal
number, we should promote:

   int -> long -> vlong.


Yeah, i was thinking
   int -> long -> vlong -> uvlong
when I wrote that, nice catch!

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T22754f10b241991c-Mba95b4da9927e1dd42b446b3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Conversion of constants in C compiler

[adr]

it's synced.

Nice.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T22754f10b241991c-Mdbeaa9de34cf64c195becdec
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Conversion of constants in C compiler

[adr]

I think I got it right at last:

[...]
   vv = yylval.vval;
   if(c1 & Numvlong ||
 (uvlong)convvtox(vv, TUVLONG) > convvtox(vv, TULONG)){
   /* unsigned suffix or hex occupying the sing bit */
   if((c1 & Numuns) || convvtox(vv, TVLONG) < 0 && (c1 & Numdec) == 
0) {
   c = LUVLCONST;
   t = TUVLONG;
   goto nret;
   }
   c = LVLCONST;
   t = TVLONG;
   goto nret;
   }
   if(c1 & Numlong ||
 (uvlong)convvtox(vv, TULONG) > convvtox(vv, TUINT)){
   if((c1 & Numuns) || convvtox(vv, TLONG) < 0 && (c1 & Numdec) == 
0) {
   c = LULCONST;
   t = TULONG;
   goto nret;
   }
   /* decimal occupying the sing bit */
   if(convvtox(vv, TLONG) < 0 && (c1 & Numdec) == 0) {
   c = LVLCONST;
   t = TVLONG;
   goto nret;
   }
   c = LLCONST;
   t = TLONG;
   goto nret;
   }
   if((c1 & Numuns) || convvtox(vv, TINT) < 0 && (c1 & Numdec) == 0) {
   c = LUCONST;
   t = TUINT;
   goto nret;
   }
   if(convvtox(vv, TINT) < 0 && (c1 & Numdec) == 0) {
   c = LLCONST;
   t = TLONG;
   goto nret;
   }
   c = LCONST;
   t = TINT;
   goto nret;
[...]

I used the cast also in (uvlong)convvtox(vv, TULONG) because the
standard only specifies that long long can't be smaller than long.

After playing with this I'm thinking about using the original code
and substituting the warning for an error when a constant is
truncated. Makes sense to me and Plan9's C isn't C99 anyway.

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T22754f10b241991c-M1f19d8edddfa4ec4ae0f5901
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Conversion of constants in C compiler

[adr]

Arrrg!

[...]
   vv = yylval.vval;
   if(c1 & Numvlong ||
 (uvlong)convvtox(vv, TUVLONG) > convvtox(vv, TULONG)){
   /* unsigned suffix or hex occupying the sing bit */
   if((c1 & Numuns) || convvtox(vv, TVLONG) < 0 && (c1 & Numdec) == 
0) {
   c = LUVLCONST;
   t = TUVLONG;
   goto nret;
   }
   c = LVLCONST;
   t = TVLONG;
   goto nret;
   }
   if(c1 & Numlong ||
 (uvlong)convvtox(vv, TULONG) > convvtox(vv, TUINT)){
   if((c1 & Numuns) || convvtox(vv, TLONG) < 0 && (c1 & Numdec) == 
0) {
   c = LULCONST;
   t = TULONG;
   goto nret;
   }
   /* decimal occupying the sing bit */
   if(convvtox(vv, TLONG) < 0 && (c1 & Numdec)) {
   c = LVLCONST;
   t = TVLONG;
   goto nret;
   }
   c = LLCONST;
   t = TLONG;
   goto nret;
   }
   if((c1 & Numuns) || convvtox(vv, TINT) < 0 && (c1 & Numdec) == 0) {
   c = LUCONST;
   t = TUINT;
   goto nret;
   }
   if(convvtox(vv, TINT) < 0 && (c1 & Numdec)) {
   c = LLCONST;
   t = TLONG;
   goto nret;
   }
   c = LCONST;
   t = TINT;
   goto nret;
[...]

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T22754f10b241991c-M489f3936d41217db381e8d09
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Conversion of constants in C compiler

[adr]

On Sun, 1 May 2022, adr wrote:


Yeah, i was thinking
  int -> long -> vlong -> uvlong


No, it was a mistake, I forgot to check again that the conversion to
unsigned when the constant is using the sign bit doesn't occurs to
decimal constants.

Also, reading 9front's mailing list I noticed the mess ignoring
that convvtox will return vlong, type casting should do the trick:

[...]
   vv = yylval.vval;
   if(c1 & Numvlong ||
 (uvlong)convvtox(vv, TUVLONG) > convvtox(vv, TULONG) ||
 (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TLONG) < 0) {
   if((c1 & Numuns) || convvtox(vv, TVLONG) < 0 && (c1 & Numdec) == 
0) {
   c = LUVLCONST;
   t = TUVLONG;
   goto nret;
   }
   c = LVLCONST;
   t = TVLONG;
   goto nret;
   }
   if(c1 & Numlong ||
 convvtox(vv, TULONG) > convvtox(vv, TUINT) ||
 (c1 & (Numdec|Numuns)) == Numdec && convvtox(vv, TINT) < 0) {
   if((c1 & Numuns) || convvtox(vv, TLONG) < 0 && (c1 & Numdec) == 
0) {
   c = LULCONST;
   t = TULONG;
   goto nret;
   }
   c = LLCONST;
   t = TLONG;
   goto nret;
   }
   if((c1 & Numuns) || convvtox(vv, TINT) < 0 && (c1 & Numdec) == 0) {
   c = LUCONST;
   t = TUINT;
   goto nret;
   }
   c = LCONST;
   t = TINT;
   goto nret;
[...]

It looks complex at first, but each line is telling you the reason
to expand the constant, and when to use unsigned types first. For
me is absolutely better than insert size assumptions in a piece of
code which is making a great effort to let that to machine dependent
code well kept in another place.

I'll make some tests.

adr

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T22754f10b241991c-M64323f2f5a4e8db8ea11250b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

> % aux/stub -d /net/etherU0 && bind /dev/etherU0 /net/etherU0
>   (for a single alias without extra clutter)

Thanks Richard, I didn't know about stub.

Shouln't the usb type be documented in the ethernet section of plan9ini(8), and 
noauto in usbd(4)?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M74e6d499395c257d841cfecf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

% aux/stub -d /net/etherU0 && bind /dev/etherU0 /net/etherU0
  (for a single alias without extra clutter)


Thanks Richard, I didn't know about stub.


Oh, and thanks for trying with your pi, I know it takes time and
I appreaciate it.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-Mb495cd40eae04d7f02c3e15a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

I've been experimenting again. With etherusb in the kernel, usbd is
triggering usb/ether and the device is mounted at /dev. I don't know
what happened before.

But there is no etherusb device.

; echo noauto ether > /dev/usbdctl
(unplug and plug again the device)
; sed /ether/q /dev/usb/ctl
...
ep9.0 enabled control rw speed super maxpkt 512 pollival 0 samplesz 0 hz 0 hub 
0 port 1 rootport 2 addr 7 idle
255 csp 0x00 csp 0x000602 csp 0x0a vid 0x0bda did 0x8153 Realtek 'USB 
10/100/1000 LAN' xhci
; usb/ether -ddd /dev/usb/ep9.0
[...]
ether: ep in /dev/usb/ep9.1 maxpkt 1024; ep out /dev/usb/ep9.2 maxpkt 1024
usb/ether: etherusb bind #l0: bad process or channel control request
usb/ether: etherusb bind #l1: bad maxpkt "bind cdc #u/usb/ep9.1/data 
#u/usb/ep9.2/data 00e04c680cfb 2000 1024"
usb/ether: etherusb bind #l2: no free devices
usb/ether: 1 buffers
usb/ether: dev ref 3
usb/ether: etherbread
usb/ether: fsadd etherU9

So bad maxpkt... etherusb check for maxpkt < 512 which is the max for
bulk transfers in usb2 high speed. Using 1024 instead fixes the problem.

Should it chek for the speed of the usb device and set the limit accordingly?


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M829ca30175f489f095e58ae9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

On Wed, 3 Aug 2022, Richard Miller wrote:

9legacy should always have up to date patches for the Raspberry Pi, and
the 9legacy SD card image will usually be fresher than the 9pi.img.gz
image in contrib/miller. The only value now in the 9pi image is for
historians: I've tried to conserve the metadata so it's possible to see
when source files were most recently changed. On 9legacy, patches are
re-applied when a distribution image is made, so mtime information is
less informative.

I will also continue to maintain the Pi kernel source in contrib/miller/9/bcm,
where a more complete history can be seen:


Ok, thanks Richard.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M92fb37694c2857c72317a3f2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

On Wed, 3 Aug 2022, Richard Miller wrote:

That was a typo, is almost five times slower (~80% slower). Just
to be clear, it is really worst!


Unless your "small arm linux machine" is a raspberry pi, you are changing
too many variables to make a meaningful comparison.  Benchmarking i/o across
the internet will also introduce enough variation to suggest an experimental
sample size of more than one attempt.

An interesting set of experiments might be to run both linux and plan 9 on
the pi4, try the built-in ether adapter and the usb dongle, and try fetching
both from http:// and https:// (to see how much of the variation is due to
tls decode speed).


Reading my mail it seems like this was something I suddenly was
aware of. It is not, I've been trying to understand what is wrong
for some time now. The pi4 saturates my fiber in linux, there is
no problem with the hardware. But note that the linux machine is
sending and receiving packages through the plan9 machine. If there
was a hardware problem in the pi4 (or the usb adapter), the linux
machine's connection would be affected.

And yes, I have made tests with different sites. As I said before
the archlinux servers usually let me saturate my bandwidth, so they
have become a good target for me.

The thing this setting is telling me is that the usb and ethernet
drivers are working reasonably good (again, at least for my
bandwidth).

I don't know any reliable server with good bandwidth serving without
tls, I could set an http server on the linux machine and make tests,
but I modified the example at

https://golangdocs.com/golang-download-files

and there is no real difference between the native and go tls implementations:

; time ./gget -o /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2
Downloaded a file /dev/null with size 513671168
2.25u 1.45s 65.51r   ./gget -o /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2

; time hget -o /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2
couldn't set mtime: permission denied
9.27u 35.02s 64.62r  hget -o /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2

With linux (again, through the plan9 machine) I get:
$ time ./gget -o /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2
Downloaded a file /dev/null with size 513671168

real0m48.624s
user0m14.265s
sys 0m21.648s

So now It is only about 25% slower in plan9, so yes, the factors are variable.

I found this thread in the list's archives:

https://marc.info/?t=14557952507=1=2

Maybe is related.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-Mf2898ed1a403f2159dda8d9a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] ramfs bug

[adr]

On Mon, 15 Aug 2022, Richard Miller wrote:

A simple fix is to add a reference count to the Ram struct, to
keep track of how many Fids point to it, and only allow a Ram to
be re-used if both busy==0 and ref==0. The new 9legacy patch
ramfs-refcount makes this change.


Thanks for sharing this with the list. It is really hard to keep
track of what and when with 9legacy.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc364b766ff6473bc-Mc0e95938ae16096f4aaad0b7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

https://es.aliexpress.com/item/1005003167747779.html

First time using usb/ether, so let me share my experience for other users.

This is on the last 9pi image at 9legacy.

First, I added a line with did=0x8153 to /sys/src/cmd/usb/usbd/usbdb.
Browsing the list's archives I thought that ether1=type=usb should be
added to the configuration file (cmdline.txt on the pi), but etherusb
wasn't in the link section of the pi4 kernel configuration file, so #l1
wasn't created. I added, compiled the kernel and then a dummy #l1 was
created, impossible to configure. I could use manually usb/ether and
configure the device mounted in /net, but usbd didn't detect the usb
card. Then I removed the ether parameters in cmdline.txt and etherusb
from pi4 to be sure, now usbd recognize the card and creates the
device /dev/etherU0. Other programs expect the devices mounted in
/net. I'm binding the device inside a directory in /tmp and then
binding this directory to /net. I would appreciate if someone shares
the correct way of doing this.

In summary, the sequence was:
ether1=type=usb in plan9.ini (cmdline.txt)
etherusb in kernel config
#l1 is created but useless
usbd doesn't work because etherusb
usb/ether works and the device appears on /net/
remove ether1=type=usb and etherusb from the kernel
now usbd works but the device doesn't appear on /net but on /dev

I finally made it work, but this is a mess, really.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-Mf7759a301a20f1a6e655ffc0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

Sorry hiro, try this
https://aliexpress.com/item/1005003167747779.html 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M77a66abad7a13dbfad7f19b7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

On Thu, 4 Aug 2022, Richard Miller wrote:

I don't know any reliable server with good bandwidth serving without tls


I am able to connect to your example arch.mirror.constant.com using
both http and https.


And now I feel like an idiot! The thing is that other tests I've
made (I'm talking about a long, long time ago) with archlinux's
mirrors allways redirected me to an htpps server, silly of me for
not trying again.

But I don't think it is the usb ethernet or the tls implementation,
I've tryed before with the internal interface and ori's experience
is similar.  I've tryed with other user agent strings, and with
the user agent string hget is using in linux's wget, but that is
not the issue. Maybe is the tcp implementation?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M353e1347db2203b819e9e672
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

On Tue, 2 Aug 2022, Richard Miller wrote:

So bad maxpkt... etherusb check for maxpkt < 512 which is the max for
bulk transfers in usb2 high speed. Using 1024 instead fixes the problem.


Thanks, the code was correct when written but the world has moved on!
Is your adapter transmitting packets successfully now?


It's working really well. I'm using David du Colombier's nat patch
(I'll post to the list another one without the il stuff in case
someone wants to try it) to share internet to a linux machine, so
I made a test from the browser (speedtest.net) and almost reached
the contracted limit of my fiber connection, although I only have
a crappy 100Mb plan (I don't really need more). So packets are
flowing, but when plan9 is more involved things get worse.

For example with this setup (a small arm linux machine connected
through plan9, using the usb adapter for internet):

linux:
$ wget -O /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2
[...]
/dev/null   100%[===>] 489.88M  10.5MB/sin 51s

2022-08-02 22:56:44 (9.58 MB/s) - ???/dev/null??? saved [513671168/513671168]


real0m51.875s
user0m8.594s
sys 0m5.379s

And the progress bar saw me several times the speed reaching my
limit. So the usb and ethernet drivers seem to be working pretty
good (at least for my bandwidth)

plan9:
; time hget -o /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2
couldn't set mtime: permission denied
8.06u 35.25s 211.17r hget -o /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2

See the difference? That's a little more than 19Mb/s, some 2MiB/s almost 50% 
slower.

By the way I don't use archlinux but I've always use their servers
to make speed tests, usually they are fast.


Actually the limit on maxpkt in that context wasn't strictly necessary anyway.
Just remove the check.


Yes, I thought the same.

adr

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M99ba4fa5f9a9f29941fe318d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

On Tue, 2 Aug 2022, Richard Miller wrote:

It should be documented somewhere, but at present it's only implemented
for the bcm kernel, and raspberry pi doesn't have a plan9.ini.


I think that cmdline.txt should be described in plan9.ini(8)


(It should be possible to move etherusb.c to /sys/src/9/port and use it on 
other platforms
too. But it's a bit of an ugly hack.)


The performance of the usb/ether driver without etherusb is much,
much worse. I think is a good idea to move it to port. Those devices
are very common nowadays, and can save your day if your ethernet
card breaks, or if your new computer has incompatible drivers, etc.

What I would love to see is the kernel creating the '#l' device
when a usb ethernet card is attached, and destroy it when the card
is unplugged. But that's the dream of an ignorant, that would already
been done if it were feasible, I suppose.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M7a30ac10a19a0a86b37f471e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

On Wed, 3 Aug 2022, adr wrote:

linux:
$ wget -O /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2

[...]
/dev/null   100%[===>] 489.88M  10.5MB/sin 51s

2022-08-02 22:56:44 (9.58 MB/s) - ???/dev/null??? saved [513671168/513671168]


real0m51.875s
user0m8.594s
sys 0m5.379s

And the progress bar saw me several times the speed reaching my
limit. So the usb and ethernet drivers seem to be working pretty
good (at least for my bandwidth)

plan9:
; time hget -o /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2

couldn't set mtime: permission denied
8.06u 35.25s 211.17r   hget -o /dev/null 
https://arch.mirror.constant.com/images/v20220801.71902/Arch-Linux-x86_64-basic-20220801.71902.qcow2


See the difference? That's a little more than 19Mb/s, some 2MiB/s almost 50% 
slower.


That was a typo, is almost five times slower (~80% slower). Just
to be clear, it is really worst!

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M34d187a3f75731aef4861b40
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[adr]

By the way Richard, should I take the last rpi image at 9legacy as
the more recent with your work? Are you going to abandon
https://plan9.io/sources/contrib/miller/?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M406ab1ba9e7ee9fe37676b4a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Acme: support spaces in file|dir names

[adr]

Hi,

this patch adds code from p9p to support spaces in file or dir
names. I use the 9front version because it has been mantained, but
there are more fixes in p9p to be imported.

adr
diff -Nur /n/9front/sys/src/cmd/acme/fns.h /sys/src/cmd/acme/fns.h
--- /n/9front/sys/src/cmd/acme/fns.hMon Jul 11 20:01:08 2022
+++ /sys/src/cmd/acme/fns.h Mon Feb 20 15:23:42 2023
@@ -90,6 +90,7 @@
 void  flushwarnings(void);
 long  nlcount(Text*, long, long, long*);
 long  nlcounttopos(Text*, long, long, long);
+Rune*  parsetag(Window*, int, int*);

 #define   runemalloc(a)   (Rune*)emalloc((a)*sizeof(Rune))
 #define   runerealloc(a, b)   (Rune*)erealloc((a), (b)*sizeof(Rune))
diff -Nur /n/9front/sys/src/cmd/acme/look.c /sys/src/cmd/acme/look.c
--- /n/9front/sys/src/cmd/acme/look.c   Mon Jul 11 20:01:08 2022
+++ /sys/src/cmd/acme/look.cMon Feb 20 15:47:24 2023
@@ -397,9 +397,9 @@
 Runestr
 dirname(Text *t, Rune *r, int n)
 {
-   Rune *b, c;
-   uint m, nt;
-   int slash;
+   Rune *b;
+   uint nt;
+   int slash, i;
   Runestr tmp;

   b = nil;
@@ -410,15 +410,13 @@
   goto Rescue;
   if(n>=1 && r[0]=='/')
   goto Rescue;
-   b = runemalloc(nt+n+1);
-   bufread(t->w->tag.file, 0, b, nt);
+   b = parsetag(t->w, n, );
   slash = -1;
-   for(m=0; m= 0; i--){
+   if(b[i] == '/'){
+   slash = i;
   break;
+   }
   }
   if(slash < 0)
   goto Rescue;
@@ -502,7 +500,7 @@
   if(nname == -1)
   nname = n;
   for(i=0; i, and turn that into an include
diff -Nur /n/9front/sys/src/cmd/acme/wind.c /sys/src/cmd/acme/wind.c
--- /n/9front/sys/src/cmd/acme/wind.c   Mon Jul 11 20:01:08 2022
+++ /sys/src/cmd/acme/wind.cMon Feb 20 15:20:37 2023
@@ -109,14 +109,26 @@
   return rr - r;
 }

+int
+delrunepos(Window *w)
+{
+   Rune *r;
+   int i;
+
+   r = parsetag(w, 0, );
+   free(r);
+   i += 2;
+   if(i >= w->tag.file->nc)
+   return -1;
+   return i;
+}
+
 void
 movetodel(Window *w)
 {
   int n;
- 
-   n = tagrunepos(w, delcmd);

-   free(delcmd);
-   delcmd = nil;
+
+   n = delrunepos(w);
   if(n < 0)
   return;
   moveto(mousectl, addpt(frptofchar(>tag, n), Pt(4, 
w->tag.font->height-4)));
@@ -141,7 +153,7 @@

   if(!w->tagexpand) {
   /* use just as many lines as needed to show the Del */
-   n = tagrunepos(w, delcmd);
+   n = delrunepos(w);
   if(n < 0)
   return 1;
   p = subpt(frptofchar(>tag, n), w->tag.r.min);
@@ -412,11 +424,7 @@

   /* w must be committed */
   n = w->tag.file->nc;
-   r = runemalloc(n);
-   bufread(w->tag.file, 0, r, n);
-   for(i=0; itag, w->tag.q0, w->tag.q1);
 }

+Rune*
+parsetag(Window *w, int extra, int *len)
+{
+   static Rune Ldelsnarf[] = { ' ', 'D', 'e', 'l', ' ', 'S', 'n', 'a', 
'r', 'f', 0 };
+   static Rune Lspacepipe[] = { ' ', '|', 0 };
+   static Rune Ltabpipe[] = { '\t', '|', 0 };
+   int i;
+   Rune *r, *p, *pipe;
+
+   r = runemalloc(w->tag.file->nc+extra+1);
+   bufread(w->tag.file, 0, r, w->tag.file->nc);
+   r[w->tag.file->nc] = '\0';
+
+   /*
+* " |" or "\t|" ends left half of tag
+* If we find " Del Snarf" in the left half of the tag
+* (before the pipe), that ends the file name.
+*/
+   pipe = runestrstr(r, Lspacepipe);
+   if((p = runestrstr(r, Ltabpipe)) != nil && (pipe == nil || p < pipe))
+   pipe = p;
+   if((p = runestrstr(r, Ldelsnarf)) != nil && (pipe == nil || p < pipe))
+   i = p - r;
+   else {
+   for(i=0; itag.file->nc; i++)
+   if(r[i]==' ' || r[i]=='\t')
+   break;
+   }
+   *len = i;
+   return r;
+}
+
 void
 winsettag1(Window *w)
 {
@@ -445,12 +485,7 @@
   /* there are races that get us here with stuff in the tag cache, so we 
take extra care to sync it */
   if(w->tag.ncache!=0 || w->tag.file->mod)
   wincommit(w, >tag);  /* check file name; also guarantees we 
can modify tag contents */
-   old = runemalloc(w->tag.file->nc+1);
-   bufread(w->tag.file, 0, old, w->tag.file->nc);
-   old[w->tag.file->nc] = '\0';
-   for(i=0; itag.file->nc; i++)
-   if(old[i]==' ' || old[i]=='\t')
-   break;
+   old = parsetag(w, 0, );
   if(runeeq(old, i, w->body.file->name, w->body.file->nname) == FALSE){
   textdelete(>tag, 0, i, TRUE);
   textinsert(>tag, 0, w->body.file->name, w->body.file->nname,

Re: [9fans] Acme: support spaces in file|dir names

[adr]

On Mon, 20 Feb 2023, hiro wrote:

9front has a p9p version? i was not aware... can you link to it?


Sorry hiro, I mean that I imported the acme version of 9front to
my system (based on 9legacy) because it has been updated along the
plan9port repo. But there are more fixes and improvements that
could be imported (to 9front's acme) from plan9port. This patch
makes 9front's acme able to open files and dirs with spaces in
their names. One thing I can't understand is why the text window
is always redrawn completely when the tag line is edited. I'll take a look
in the future.

Anyway, I remember seeing a version of plan9port with the apps from
9front somewhere, I'm surprised you didn't know about it.

adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc1d9d9ca3a94e285-M5b0a4879bb3a257cf8f7ebd4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Usb audio on rpi4 (9legacy)

[adr]

Hi, I've problems using usb audio boards on rpi4 9legacy. Before I dig in, I 
would appreciate
if someone can share his/her experience. The idea is to rule out xhci bugs with 
isochronous transfers.

regards,
adr
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1581124767d20893-M8472cba66cbb0381b69da4a3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Panic with 'compose-x' input

[adr]

Hi,

this patch fixes the issue, but other platforms' kbd.c files must be
corrected too. I'm only using arm.

adr
--- /n/sources/plan9/sys/src/9/omap/kbd.c   Mon Mar 17 16:50:34 2014
+++ /sys/src/9/omap/kbd.c   Sat Feb 11 23:59:45 2023
@@ -208,7 +208,7 @@
   int shift;
   int collecting;
   int nk;
-   Runekc[5];
+   Runekc[UTFmax*2+1];
   int buttons;
 };

--- /n/sources/plan9/sys/src/9/port/latin1.cTue Apr 30 16:05:23 2013
+++ /sys/src/9/port/latin1.cSun Feb 12 00:09:27 2023
@@ -20,7 +20,7 @@
 long
 unicode(Rune *k, int n)
 {
-   long c;
+   ulong c;
   Rune *r;

   c = 0;
@@ -35,6 +35,8 @@
   else
   return -1;
   }
+   if(c > 0x10)
+   return -1;
   return c;
 }

@@ -59,7 +61,7 @@
   if(n>=UTFmax*2+1)
   return unicode(k, UTFmax*2+1);
   else
-   return -(UTFmax+1);
+   return -(UTFmax*2+1);
   for(l=latintab; l->ld!=0; l++)
   if(k[0] == l->ld[0]){
   if(n == 1)
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2e9c8ba406c24ea7-Mbf6f52450dab45b5d23393e4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
--- /n/sources/plan9/sys/src/9/omap/kbd.c	Mon Mar 17 16:50:34 2014
+++ /sys/src/9/omap/kbd.c	Sat Feb 11 23:59:45 2023
@@ -208,7 +208,7 @@
 	int	shift;
 	int	collecting;
 	int	nk;
-	Rune	kc[5];
+	Rune	kc[UTFmax*2+1];
 	int	buttons;
 };
 
--- /n/sources/plan9/sys/src/9/port/latin1.c	Tue Apr 30 16:05:23 2013
+++ /sys/src/9/port/latin1.c	Sun Feb 12 00:09:27 2023
@@ -20,7 +20,7 @@
 long
 unicode(Rune *k, int n)
 {
-	long c;
+	ulong c;
 	Rune *r;
 
 	c = 0;
@@ -35,6 +35,8 @@
 		else
 			return -1;
 	}
+	if(c > 0x10)
+		return -1;
 	return c;
 }
 
@@ -59,7 +61,7 @@
 		if(n>=UTFmax*2+1)
 			return unicode(k, UTFmax*2+1);
 		else
-			return -(UTFmax+1);
+			return -(UTFmax*2+1);
 	for(l=latintab; l->ld!=0; l++)
 		if(k[0] == l->ld[0]){
 			if(n == 1)

[9fans] Re: USB Audio on RPi 4

[adr]

On Mon, 13 Feb 2023, Steve Taylor wrote:


From: Steve Taylor 
Hello adr,

I saw your note on the Plan 9 mailing list about USB audio on the RPi 4 with 
9legacy. By USB audio device, do you mean something like a USB DAC? If so, I 
have spent several hours on this recently. Whenever I play audio through my USB 
DAC connected to my RPi4, using either 9legacy or 9front, I hear pops and other 
small noises like static. I think it is from dropped frames. If I use OpenBSD 
on the same hardware, these issues do not occur. The audio plays perfectly.

Are you seeing issues like this?

I am curious if using a USB DAC which is USB 1.0 would work properly. I 
identified a couple I could try, but they are about 20 years old and difficult 
to find for a decent price. The USB DAC I have now uses xhci.

Thanks,

Steve


Hi Steve,

I'm using this cheap one:

https://aliexpress.com/item/1005001394902427.html

ep6.0 enabled control rw speed full maxpkt 8 pollival 0 samplesz 0 hz 0 hub 3 
port 4 rootport 1 addr 4 busy
audio csp 0x000101 csp 0x000201 csp 0x000201 csp 0x03 vid 0x1b3f did 0x2008 
GeneralPlus 'USB Audio Device' xhci
ep6.5 enabled iso w speed full maxpkt 180 pollival 1 samplesz 4 hz 44100 hub 3 
port 4 rootport 1 addr 4 busy
ep6.6 enabled iso r speed full maxpkt 96 pollival 1 samplesz 2 hz 48000 hub 3 
port 4 rootport 1 addr 4 idle
ep6.3 enabled interrupt r speed full maxpkt 8 pollival 32 samplesz 0 hz 0 hub 3 
port 4 rootport 1 addr 4 busy

It works ok with 9front. If you just need decent audio output from
your pi, I recommend it.

Now about 9legacy. Richard Miller imported the xhci driver from
9front, so I compared them. The only real difference appart from
IN isochronous transfers support is the addition of sample delay
for buffering. This patch makes the already present control in
usb/audio Delay_control an internal one to set this delay. I used
the same default as 9front, 40ms. I can play audio perfectly now.
Also you can change now the sample rate (speed), the code was
reopening the endpoint with openep() every time setspeed() was
called. More work has to be done, but for now I hope this is helpful
for you.

Try increasing the delay with your device.

I'm sharing this with the list.

P.S. The patch is against the repo at github.com/0intro/plan9-contrib.

Regards,
adr

--- /n/downloads/devusb.c   Tue Feb 14 20:42:27 2023
+++ /sys/src/9/bcm/devusb.c Tue Feb 14 11:31:28 2023
@@ -88,6 +88,7 @@
   CMdebugep,  /* debug n (set/clear debug for this ep) */
   CMname, /* name str (show up as #u/name as well) */
   CMtmout,/* timeout n (activate timeouts for ep) */
+   CMsampledelay,  /* maximum delay introduced by buffering (iso) 
*/
   CMpreset,   /* reset the port */

   /* Hub feature selectors */
@@ -128,6 +129,7 @@
   {CMclrhalt, "clrhalt",  1},
   {CMname,"name", 2},
   {CMtmout,   "timeout",  2},
+   {CMsampledelay, "sampledelay",  2},
   {CMpreset,  "reset",1},
 };

@@ -1387,6 +1389,11 @@
   ep->tmout = strtoul(cb->f[1], nil, 0);
   if(ep->tmout != 0 && ep->tmout < Xfertmout)
   ep->tmout = Xfertmout;
+   break;
+   case CMsampledelay:
+   if(ep->ttype != Tiso)
+   error("ctl ignored for this endpoint type");
+   ep->sampledelay = strtoul(cb->f[1], nil, 0);
   break;
   case CMpreset:
   deprint("usb epctl %s\n", cb->f[0]);
--- /n/downloads/usbxhci.c  Tue Feb 14 20:41:33 2023
+++ /sys/src/9/bcm/usbxhci.cTue Feb 14 11:24:53 2023
@@ -194,6 +194,7 @@

   int stopped;

+   int *residue;
   Wait*pending;
   Lock;
 };
@@ -277,6 +278,10 @@
   u32int  incr;
   u32int  tdsz;

+   /* isoread */
+   u32int  rp0;
+   u32int  frame0;
+
   int nleft;
 };

@@ -1100,10 +1105,17 @@
 {
   if(io->ring == nil)
   return;
-   io->frame = 0;
-   io->period = ep->pollival<<3*(ep->dev->speed == Fullspeed);
-   io->incr = (ep->hz*io->period<<8)/8000;
-   io->tdsz = (io->incr+255>>8)*ep->samplesz;
+   io->rp0 = io->ring->wp;
+   io->frame0 = io->frame = 0;
+   io->period = ep->pollival << 3*(ep->dev->speed == Fullspeed || 
ep->dev->speed == Lowspeed);
+   if(io->ring->id & 1){
+   io->ring->residue = 
smalloc((io->ring->mask+1)*sizeof(io->ring->residue[0]));
+   io->incr = 0;
+   io->tdsz = ep->maxpkt*ep->ntds;
+   } else {
+   io->incr = ((vlong)ep->hz*ep->pollival<<8)/1000;
+   io->tdsz = (io->incr+2

[9fans] Re: Panic with 'compose-x' input

[adr]

I forgot about Runemax, better to use it instead of 0x10.

Just to be clear, without this entering a unicode character represented by more 
than 4 runes (compose key, then x key) will produce a system panic. This thing 
has been boring me for a while by accident, I didn't imagine this was the cause.

adr
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2e9c8ba406c24ea7-M5236348a6a9fea48917117ee
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Miller's 9pi image (rpi4) problems

[adr via 9fans]

> > Some modern disks use the "UASP"
> > protocol in preference to the traditional bulk-only mass storage protocol
> > supported by the Plan 9 usbdisk driver. Even if the disk also supports
> > bulk-only, the existing driver won't try to pick an alternate configuration
> > to force the disk to fall back to that protocol. Below is a patch (tested on
> > only one drive, as far as I know) which will make it do that.
> 
> Thanks, I'll give it a try.

No luck!, although the end points appear now after manually executing
usb/disk.

kprint when attaching the disk:
usb/disk... usb/hub... /boot/usbd: disk: disk: endpoints not found
usb/disk... 

; cat /dev/usb/ctl
ep1.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 0 
port 0 rootport 0 addr 0 busy
roothub csp 0x09 ports 1 xhci
ep2.0 enabled control rw speed super maxpkt 512 pollival 0 samplesz 0 hz 0 hub 
0 port 0 rootport 0 addr 0 busy
roothub csp 0x09 ports 4 xhci
ep3.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 0 
port 1 rootport 1 addr 1 busy
hub csp 0x010009 ports 4 none  xhci
ep8.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 1 
port 3 rootport 1 addr 6 busy
hub csp 0x020009 ports 4 'VIA Labs, Inc. ' 'USB2.0 Hub ' 
xhci
ep5.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 1 
port 4 rootport 1 addr 3 busy
hub csp 0x010009 ports 4 'USB Device  ' 'USB 2.0 Hub' xhci
ep6.0 enabled control rw speed low maxpkt 8 pollival 0 samplesz 0 hz 0 hub 3 
port 1 rootport 1 addr 4 busy
hid csp 0x020103 vid 0x1c4f did 0x0078 SIGMACHIP 'SG 2.4G Wireless Mouse' xhci
ep6.2 enabled interrupt r speed low maxpkt 8 pollival 10 samplesz 0 hz 0 hub 3 
port 1 rootport 1 addr 4 busy
ep7.0 enabled control rw speed low maxpkt 8 pollival 0 samplesz 0 hz 0 hub 3 
port 2 rootport 1 addr 5 busy
hid csp 0x010103 csp 0x03 vid 0x0c45 did 0x9510 S U xhci
ep7.1 enabled interrupt r speed low maxpkt 8 pollival 10 samplesz 0 hz 0 hub 3 
port 2 rootport 1 addr 5 busy
ep9.0 enabled control rw speed high maxpkt 64 pollival 0 samplesz 0 hz 0 hub 6 
port 3 rootport 1 addr 8 idle
storage csp 0x500608 csp 0x620608 vid 0x0bc2 did 0xaa14 Seagate Basic xhci

; usb/disk -dD /dev/usb/ep9.0
usb/disk: fsioproc pid 332
<- Tversion tag 65535 msize 8216 version '9P2000'
-> Rversion tag 65535 msize 8216 version '9P2000'
<- Tauth tag 12 afid 394 uname adr aname 
-> Rerror tag 12 ename permission denied
<- Tattach tag 12 fid 394 afid -1 uname adr aname 
-> Rattach tag 12 qid ( 0 d)
usb/disk: startdevs: opening #0 /dev/usb/ep9.0
usb/disk: opendev 0x4e5d8 /dev/usb/ep9.0
usb/disk: /dev/usb/ep9.0 csp storage.6.80 vid 0xbc2 did 0xaa14 refs 1
Seagate Basic NABC5SSF
conf: cval 1 attrib 80 500 mA
iface csp storage.6.80
  alt 0 attr 2 ival 0
disk: ep ids: in 1 out 2
usb/disk: opendev 0x50d98 /dev/usb/ep9.1
usb/disk: /dev/usb/ep9.1: maxpkt 512
usb/disk: /dev/usb/ep9.1: ntds 1
usb/disk: opendev 0x50e58 /dev/usb/ep9.2
usb/disk: /dev/usb/ep9.2: maxpkt 512
usb/disk: /dev/usb/ep9.2: ntds 1
disk: ep in /dev/usb/ep9.1 out /dev/usb/ep9.2
disk: /dev/usb/ep9.0: maxlun 0
disk: cmd: tag 0x1:  12 00 00 00 ff 00 datalen: 255
disk: data: 76 bytes
disk: status: 00 residue: 179
disk: cmd: tag 0x2:  1b 00 00 00 01 00 datalen: 0
disk: status: 00 residue: 0
disk: cmd: tag 0x3:  25 00 00 00 00 00 00 00 00 00 datalen: 8
disk: data: 8 bytes
disk: status: 00 residue: 0
disk: cmd: tag 0x4:  9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00 datalen: 32
disk: data: 32 bytes
disk: status: 00 residue: 0
disk: logical block size 512, # blocks 7814037167
usb/disk: fsadd sdU9.0

; ls /dev/sd*
/dev/sdM0/ctl
/dev/sdM0/data
/dev/sdM0/dos
/dev/sdM0/fossil
/dev/sdM0/nvram
/dev/sdM0/plan9
/dev/sdM0/raw
/dev/sdctl

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc5dcd85d69518168-M8ba5098a8a830998e7df9632
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription