Re: [9fans] Request for (constructive?) comments: Plan 9 : 2020

[erik quanstrom]

vashon has a high density of fans.  :-). (hi, skip). seriously, an iwp9 anywhere would be great.  bonus points for good weather.- erikOn Oct 24, 2019 02:45, Jonas Amoson  wrote:A new IWP9 would be great, and I’d be happy to help out in the preparation if needed and wanted, e.g. reading submissions, helping with troff formatting of papers or such (although no expert really).Regarding location, I’d try to attend anywhere suggested. The more important here is that some people are taking the initiative. Although anywhere Europe would be much closer to where I am, I think that the place might be more of an issue if it would happen more frequently than every five year :-)Jonas
<-Ursprungligt Meddelande->  From: Iruat� Souza [iru.mu...@gmail.com]
Sent: 23/10/2019 10:36:41 AM
To: 9fans@9fans.net
Subject: Re: [9fans] Request for (constructive?) comments: Plan 9 : 2020 
?I suggest we do it somewhere in Europe. I have the impression most

active users are here.

On Wed, Oct 23, 2019 at 8:58 AM Steve Simon  wrote:

>

> hi,

>

> i love the idea, what concerns me is the cost of a flight from the UK to Michigan.

>

> we shall see what tickets i can find.

>

> -Steve

>

>

> > On 23 Oct 2019, at 6:49 am, o...@eigenstate.org wrote:

> >

> > ?

> >>

> >> Jeff (jas) and I have been chatting about organizing a "Plan 9 : 2020"

> >> workshop.  We're trying to gauge everyone's interest, and to solicit agenda

> >> items, venue suggestions, and hopefully volunteers to help organize it.

> >

> > I'd be interested in attending, and I don't mind taking some time to

> > help organize.

> >

> >> If you have a different suggestion, or are willing to offer a venue, please

> >> comment.

> >

> > Some of us have also been talking about planning an OpenBSD-style

> > hackathon.  (OpenBSD hackathons: Get developers in a room, and write

> > code for a week, exchanging ideas, trying to get commits into base and

> > ports.  Beer is usually involved.)

> >

> > We'd discussed putting together something like that for Plan 9 in the

> > first half of 2020. Anyone hacking on Plan 9 related code would be

> > welcome.

> >

> > I don't know if this is a different suggestion so much as a different

> > event.  Experience implies that merging the two together may be a bit

> > too much in one shot.

> >

> > Expect a post about that when we start sorting out the details.

> >

--

9fans: 9fans

Permalink: https://9fans.topicbox.com/groups/9fans/T63bc6dc40f27ab23-M8b84343762c7f6f77e36d786

Delivery options: https://9fans.topicbox.com/groups/9fans/subscription9fans
  / 9fans / see
discussions
  +
participants
  +
delivery options
Permalink

9fans
  / 9fans / see
discussions
  +
participants
  +
delivery options
Permalink

Re: [9fans] Git/fs: Possibly Usable

[erik quanstrom]

the reason for this addition was a bug I found in coraid usage of rc scrips where one script set ifs, and called another which did not reset ifs.  in retrospect this appears to be a regression over the Bourne she'll due to the elimination of export.  anyway, rather than forcing all scripts to defensively use ifs, I thought it would be easier to sunset the use of ifs.- erik

Re: [9fans] Git/fs: Possibly Usable

[erik quanstrom]

yes, that's my change and it was introduced in 9atom, along with allowing newlines within lists.- erikOn Aug 5, 2019 11:43, Skip Tavakkolian  wrote:is this an equivalent fix for 9legacy env?  (i'm guessing the answer is no)% diff clone /bin/git/clone75c75< 		for(f in `$nl{walk -f $tree | sed 's@^'$tree'/*@@'}){---> 		for(f in `{ifs=$nl walk -f $tree | sed 's@^'$tree'/*@@'}){also, the earliest reference to `$split{...}` notation i found is in 9atom; can anyone confirm?On Thu, Jul 25, 2019 at 3:01 PM Ori Bernstein  wrote:On Sun, 21 Jul 2019 16:06:54 -0500
clueelf@tonymendoza.us wrote:

> Thanks Ori!
> 
> I pulled it down today and started using it against a few GitHub repos I have.  For those who are thinking about using it, it only uses 'git' and 'git+ssh' style URLs, but they work so far without incident.  
> 
> git/clone git+ssh://git@github.com:tmendoza/9front-user
> 
> Once I got keys generated and pushed to github.com, worked just fine.  My updates show up as expected.

Good to hear!

-- 
Ori Bernstein 

Re: [9fans] Understanding /dev/draw

[erik quanstrom]

I think the missing stuff is in libmemdraw.On Apr 18, 2019 12:03, Chris McGee  wrote:Hi All,I managed to get it running after all of these years. In case anyone tries it again here's a few things that I had to do to get it to work on the latest 9front.* Copy the latin1.h header file from the bell labs distribution and copy it into /sys/src/9/port* Run ip/httpd/httpd -w /sys/web/9wd (this is where the installation copies the web app)* Patch /usr/web/9wd/js/draw/data.js by commenting out the "delete conn.imgs[id];" line    * Future draw commands come in referring to the old image for some reason and the server doesn't handle it wellYes, when I coerce the websocket tool to launch rio instead of acme there's some oddness when I launch new graphical apps within rio from the windows, such as acme. They tend to think that they should occupy the entire screen. Also, be patient because it is quite slow for now.Does anyone know if David is still active in this space?Erik, where can I learn more about the layers?Thanks,ChrisOn Thu, Apr 18, 2019 at 2:08 PM erik quanstrom <quanstro@quanstro.net> wrote:this implementation is enough to run acme,but not a full p9 terminal.  you'll need layers for that.

Re: [9fans] Understanding /dev/draw

[erik quanstrom]

this implementation is enough to run acme,but not a full p9 terminal.  you'll need layers for that.- erikOn Apr 18, 2019 10:27, Skip Tavakkolian  wrote:Improving or reimplementing it better are just as important as originality.On Thu, Apr 18, 2019 at 9:51 AM Chris McGee  wrote:Thanks, this looks to be exactly what I was hoping to do. The idea wasn't as original as I thought.On Thu, Apr 18, 2019 at 11:27 AM Skip Tavakkolian  wrote:This might be a good place to start:https://bitbucket.org/dhoskin/9webdraw/src/default/On Thu, Apr 18, 2019 at 7:36 AM Chris McGee  wrote:Hi All,I'm looking at creating an alternate filesystem for /dev/draw, /dev/mouse and /dev/kbd that hooks up to a web server providing HTML interfaces (e.g. canvas) for Plan 9 UI. I've been reading over the manual pages, which are quite detailed, which is great, but there are some points of confusion for me.In particular, /dev/draw's interface and documentation keep referring to the concept of a "window" indirectly. It seems that in some cases the server providing /dev/draw needs to track windows and refresh them. But, what defines a window in this protocol? Is every image a window or only some of them?Also, I'm trying to understand how off-screen images, such as fonts are loaded. It seems that every image must be associated with a screen and be given a position within the screen. So, how do you prevent the image from being visible to the user?Hopefully, if I can understand some of the high-level concepts here then the manual page will be all that I need. Does anyone have experience with this area or could point me to information that might help clarify it?My next step will probably be to figure out how libmemdraw does all of this on top of a frame buffer.Thanks,Chris

Re: [9fans] Rc port.

[erik quanstrom]

correct.  Doug's original proposal was very nonlinear.  Ken's genius was finding an implementable and useful subset.- erikOn Jan 25, 2019 07:13, Stuart Morrow  wrote:I take back the stuff where a directory can be a command  - it interacts weird with $path:you’d do `..’ thinking it’s the same as `cd ..’, except it’s actually `cd /bin/..’. > is there a buildable version of es any longer? I just found    http://wryun.github.io/es-shell/ I’ve never actually used es, this or any other version; this is the first I’ve heard youcouldn’t just use the original. Hey, does anybody know if Tom Duff really invented process substitution? ( <{} )There’s a comment in ‘A Retrospective’ (1978, I think - it’s in the 1978 BSTJ edition`UNIX Time-Sharing System’; I have a tenth-anniversary reprint called ‘UNIX SystemReadings And Applications’) by Dennis Ritchie about how a syntax for non-linearpipelines has already been proposed. /dev/fd wouldn’t have existed yet, so doesanybody know what he’s referring to here? Whoever it was, I bet it was Doug. -Morrow 

Re: [9fans] Rc port.

[erik quanstrom]

is there a buildable version of es any longer?  es is interesting, and worth a look but I think it failed to justify it's extra-user visible layers.I wrote a shell similar to rc before Byron's almost-clone.  mirroring Duff's comments about sh, beating rc is not easy.  the bar is really high.- erik

Re: [9fans] Plumber architecture question

[erik quanstrom]

you need plumber so cpu can be transparent to plumbing.- erik

Re: [9fans] Upas and Message-ID?

[erik quanstrom]

not sure if that was changed, but nupas creates messageids and maintains messageids references.- erik

Re: [9fans] upas : without acme : possible?

[erik quanstrom]

Ned is what I usually use.  I don't use any accompanying scripts, but I've made a number of changes to ned itself.  I find g/unwanted/d to be way more efficient than acme.- erik

Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller

[erik quanstrom]

I typically use CEC instead of a real serial console.- erik

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

[erik quanstrom]

> It's useful internally in protocol implementation, specifically to avoid
> copying in transport protocols (for later retransmission), and the
> modifications aren't vast.
> A few changes were trickier, often because of small bugs in the original
> code. icmp does some odd things i think.

that makes sense.  likewise, if it were essentially free to add file systems in 
the i/o path,
from user space, one could build micro file systems that took care of small 
details without
incuring much cost.  ramfs is enough of a file system if you have other 
programs to do
other things like dump.

> I'll see if I wrote up some of it. I think there were manual pages for the
> Messages replacing Blocks.

that would be great.  thanks.


> My mcs lock implementation was probably more useful, and I use that in my
> copy of the kernel known as 9k

indeed.  i've seen great performance with mcs in my kernel.

- erik

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[erik quanstrom]

> > with meltdown/Spectre mitigations in place, I would like to see evidence 
> > that flip is faster than copy.
> 
> If your system is well balanced, you should be able to
> stream data as fast as memory allows[1]. In such a system
> copying things N times will reduce throughput by similar
> factor. It may be that plan9 underperforms so much this
> doesn't matter normally.

sure.  but flipping page tables is also not free.  there is a huge cost in 
processor stalls, etc.
spectre and meltdown mitigations make this worse as each page flip has to be 
accompanied
by a complete pipeline flush or other costly mitigation.  (not that this was 
cheap to begin with)

it's also not an object to move data as fast as possible.  the object is to do 
work as fast as possible.

> [1] See: https://code.kx.com/q/cloud/aws/benchmarking/
> A single q process can ingest data at 1.9GB/s from a
> single drive. 16 can achieve 2.7GB/s, with theoretical
> max being 2.8GB/s.

with my same crappy un-optimized nvme driver, i was able to hit 2.5-2.6 GiB/s
with two very crappy nvme drives.  (are you're numbers really GB rather than 
GiB?)
i am sure i could scale that lineraly.  there's plenty of memory bandwidth 
left, but
i haven't got any more nvme.  :-)

similarly coraid built an appliance that did copying (due to cache) and hit 1 
million
4k iops.  this was in 2011 or so.

but, so what.  all this proves is that with copying or without, we can ingest 
enough
data for even the most hungry programs.

unless you have data that shows otherwise.  :-)

- erik

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[erik quanstrom]

zero copy is also the source of the dreaded 'D' state.- Erik

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[erik quanstrom]

I have been able to copy 1 GiB/s to userspace from an nvme device.  I should think a radio should be no problem.- Erik

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[erik quanstrom]

>  From what I recall, PDP11 hardware memory management was based on
> segmentation rather than paging (64K divided into 16 variable sized
> segments), and Unix did swapping rather than paging (a process is either
> completely in memory or completely on disk). It does relocation and

completely in memory /and running/. or swapped out.

- erik

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[erik quanstrom]

> I think it would be terrible, because I got frustrated enough trying to run a 
> 4e CPU server with graphics on a 2GB x86.  I kept running out of image 
> memory!  The trouble was the draw device in 4th edition stores images in the 
> same "image memory" the kernel loads programs into, and the 386 CPU kernel 
> 'only' allocates 64MB of that. :)  

this was changed long ago.  image memory can now be much bigger.  i never had a 
problem when a 4e terminal
was my daily driver.

- erik

Re: [9fans] Plan9 on Pi 3B+

[Erik Quanstrom]

I would guess it's a bug because the second bug is starting the first loop st 0- erik

Re: [9fans] nupas

[Erik Quanstrom]

I continue to use nupas on s daily basis with imap.- erik

Re: [9fans] There is no fork

[Erik Quanstrom]

I am still using and maintaining 9atom.  I just have a busy schedule so read the list less.- erikOn Feb 11, 2018 14:48, Benjamin Huntsman  wrote:

> 9atom and 9front are both actively maintained.


It seems like 9atom is not actually actively maintained any longer.  I hope Erik sees this and refutes me, though!
I was aware of Harvey, Jehanne, and plan9-9k, though I didn't mention them because I wasn't sure how "mainstream" they
 were, or if there was active development in the case of plan9-9k.  Please pardon me. :)


To be honest, I was sort of hoping to hear someone say that 9atom with the NIX kernel is the way to go.  Unfortunately, I mostly use VMware and a few old-ish but still 64-bit ThinkPads,
 and 9atom won't so much as boot on any of them.  Anyone on here managed to get 9atom to run in VMware or on a W500-series (500, 520, 530)  ThinkPad?


Or, if one wants NIX but to stay a little closer to the original distribution, are there options, or is Harvey the only way?


Anyway, I also want to say thank you to the smart people on this list who have maintained and advanced Plan 9 in its
 various forms over the years!!


Thanks.


-Ben




From: 9fans-bounces@9fans.net <9fans-bounces@9fans.net> on behalf of Giacomo Tesio 
Sent: Sunday, February 11, 2018 4:26 AM
To: Fans of the OS Plan 9 from Bell Labs
Subject: Re: [9fans] There is no fork
 


To my knowledge this is the set of active projects based on Plan 9:

9atom and 9front are both actively maintained.
Both stick strongly to the original Plan 9 from Bell Labs design.
AFAIK, 9front introduce more innovations, both in kernel and in user
space, but what make it unique is the #cat-v community.

9legacy is not a really fork, but an organized collection of patches,
and is still actively maintained.
Another non-fork active project is Plan 9-ANTS
(http://www.9gridchan.org/ ) which also provides a 9front-based amd64
iso and a free 9P grid online.

Harvey's kernel is based on NIX, and AFAIK, it's the only project
where NIX development is active.

Forsyth's Plan-9k had some development in mid 2017.
It's 2015 version was the starting point of Jehanne's kernel, which is
my own research operating system (that also includes several of
9front's improvements).
Jehanne is the project that diverged most from the original Plan9
design, with its own set of crazy decisions, but currently it's an
unstable toy.


Giacomo

2018-02-10 3:48 GMT+01:00 Benjamin Huntsman :
> Just curious as to the state of the union.  Is 9front pretty much the de
> facto "official" Plan 9 these days, or does anyone still use or maintain any
> of the following:
>
>
> 9atom
>
> NIX
>
> 9legacy
>
> The original Bell Labs distribution
>
>
> Thanks for your input!
>
>
> -Ben
>
>

Re: [9fans] SCMs

[Erik Quanstrom]

well of course a worm is only equivalent if a user can snap and name any part of the tree at any time, and creat a new tree from any historical point.- erik

Re: [9fans] software archaeology

[Erik Quanstrom]

I think that's all it did.  musta been 4e- erikOn Feb 4, 2018 20:24, Benjamin Huntsman  wrote:

Bizarre and random question, but anyone still have any of the original 3rd Edition floppy images around?


Also, anyone remember, did the web-based floppy builder from back in the day actually do anything other than tweak the plan9.ini?


Thanks!

Re: [9fans] SMART: Silly Marketing Acronym, Rebuts Truth

[Erik Quanstrom]

in my experience smart can be helpful diagnosing grey failures.  but it's useless to generalize about hdd or ssd firmware wrt smart data.  

Re: [9fans] Spectre and Meltdown

[Erik Quanstrom]

it is also exploitable in node.js.On Jan 10, 2018 12:52, Skip Tavakkolian <skip.tavakkol...@gmail.com> wrote:i think "_javascript_ in the browser" is implied here. and that is a HUGE gate to close.fortunately, we don't have such browsers in plan9 :)On Wed, Jan 10, 2018 at 11:41 AM, Erik Quanstrom <quanstro@quanstro.net> wrote:to be fair, this vulnerability can be exploited with plain old _javascript_.On Jan 10, 2018 11:32, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:good advice. i agree with the wait-and-see. i'm not convinced that this issue is solvable.using pip, npm and all the other ways of importing random code from who-knows-where is insanity and plan9 systems (mostly?) avoid this practice.having dedicated auth and fs servers (don't allow cpu'ing) and using terminals for each user is a good practice.a terminal on an affected processor can still compromise your factotum data in memory. rpi3 is a safe choice and, for plan9, probably the best choice.On Wed, Jan 10, 2018 at 8:59 AM,  <cinap_lenrek@felloff.net> wrote:wait and see if all these scrambled together mitigations actually work.

9front is not in the business of selling shared computing environments
(or sell executable _javascript_ ads) to untrusted strangers.

that was never really safe to begin with. there will be bugs in software
and hardware. and there will be side channels.

if you are concerned about security and leaks then run your authentication
server on a dedicated box and applications on your own terminal.

--
cinap

Re: [9fans] Spectre and Meltdown

[Erik Quanstrom]

this is different.  the side channel attack is easy and completes in milliseconds.  it is not related to the expressiveness of js.- erik

Re: [9fans] Spectre and Meltdown

[Erik Quanstrom]

to be fair, this vulnerability can be exploited with plain old _javascript_.On Jan 10, 2018 11:32, Skip Tavakkolian  wrote:good advice. i agree with the wait-and-see. i'm not convinced that this issue is solvable.using pip, npm and all the other ways of importing random code from who-knows-where is insanity and plan9 systems (mostly?) avoid this practice.having dedicated auth and fs servers (don't allow cpu'ing) and using terminals for each user is a good practice.a terminal on an affected processor can still compromise your factotum data in memory. rpi3 is a safe choice and, for plan9, probably the best choice.On Wed, Jan 10, 2018 at 8:59 AM,   wrote:wait and see if all these scrambled together mitigations actually work.

9front is not in the business of selling shared computing environments
(or sell executable _javascript_ ads) to untrusted strangers.

that was never really safe to begin with. there will be bugs in software
and hardware. and there will be side channels.

if you are concerned about security and leaks then run your authentication
server on a dedicated box and applications on your own terminal.

--
cinap

Re: [9fans] double lock in proc.c

[Erik Quanstrom]

I had a discussion with Richard about this a few years ago.  Richard was no longer convinced of the solution.  at the time I agreed with his reasoning.  the comment should be changed.- erikOn Jul 24, 2017 9:03 AM, Giacomo Tesio  wrote:In /sys/src/9/port/proc.c a comment state:/** Expects that only one process can call wakeup for any given Rendez.* We hold both locks to ensure that r->p and p->r remain consistent.* Richard Miller has a better solution that doesn't require both to* be held simultaneously, but I'm a paranoid - presotto.*/(see https://github.com/0intro/plan9/blob/master/sys/src/9/port/proc.c#L882-L887)I'd like to know a bit more about Miller's solution as I'd like to simplify postnote.Any hint or source code?Giacomo

Re: [9fans] equality sign in Rc

[Erik Quanstrom]

by doing it in the grammar, the redirection issue is avoided.- erikOn May 16, 2017 2:24 AM, Charles Forsyth  wrote:On 15 May 2017 at 17:44, trebol  wrote:> = is part of rc syntax, like {} and (), and it interprets it, not thei'd forgotten about the = in >[2=1], so you'd need another exception ...rc would interpret that, but then in [a-b=] it presumably wouldn't again...

Re: [9fans] equality sign in Rc

[Erik Quanstrom]

my purpose was to answer the question posed in the list.  iirc, rsc proposed this solution as well.  I have to mention that this is no funkier than allowing "echo if", which rc does.  I also have to mention that I'm not yet convinced of this change.  but it sure is no fun to quote every arg to certain programs.- erik

Re: [9fans] equality sign in Rc

[Erik Quanstrom]

there is no winning.if we implement the right thing, then arguments like --fu=bar will be 'eaten silently' from the perspective of the (human) operator.  sure gigo, but this seems extra hard o get right in a Unix environment.- erikOn May 15, 2017 08:42, Charles Forsyth <charles.fors...@gmail.com> wrote:On 15 May 2017 at 16:37, Erik Quanstrom <quanstro@quanstro.net> wrote:I implemented the Unix mistake as this hack is for p9p.  I'm not sure I like it.  it's interesting to note that = is still not allowed in a list.Great. So now there are two different rc conventions.perhaps {} should be treated specially after the first word so find can be used.

Re: [9fans] equality sign in Rc

[Erik Quanstrom]

yes.  nothing can break.I implemented the Unix mistake as this hack is for p9p.  I'm not sure I like it.  it's interesting to note that = is still not allowed in a list.- erikOn May 15, 2017 04:56, Charles Forsyth  wrote:On 15 May 2017 at 12:54, Charles Forsyth  wrote:and = would be handled by rc uniformly.It also wouldn't break anything, because nothing currently can use unquoted =,and things that used quoted = would work just as before.

Re: [9fans] equality sign in Rc

[erik quanstrom]

> You can force rc to setting a variable only if = is surrounded by spaces, 
> like in sh, but then you'll have a lot of problems in plan9/p9p.

nack.  disregarding the confusion about spaces, incompatible changes aren't ok.
i've heard the argument that one can't make language progress without breaking 
things.
c is a counter example.  so far, rc has been as well.

- erik

Re: [9fans] equality sign in Rc

[erik quanstrom]

On Sun May 14 08:32:47 PDT 2017, trebol55...@yandex.ru wrote:
>  > That isn't sh's rule. x=y is fine as an assignment without spaces.
> 
> Yes, sorry, in fact I was thinking on the contrary I wrote: don't set a 
> variable like in sh.
> 
> I like the use of spaces permitted in rc, as I said.

i was about to make this correction myself.  in any event, this is a sloppy but 
effective pure extension
to the grammar that allows everything but the first word to contain an '='.

since this is done at the grammar level, and not as one would expect at the 
lexer level, there are some
surprises like a function with "echo x=1" will deparse as echo 'x='^1.  not 
perfect, but workable

here's the code change

../rc/syn.y:24,35 - syn.y:24,47
return !i;
  }
  
+ tree*
+ treeeq(int type, tree *c0, tree *c1)
+ {
+   char *old;
+ 
+   old = c0->str;
+   c0->str = smprint("%s=", c0->str);
+   c0->quoted = 1;
+   free(old);
+   return tree2(type, c0, c1);
+ }
+ 
  %}
  %union{
struct tree *tree;
  };
  %type line paren brace body cmdsa cmdsan assign epilog redir
- %type cmd simple first word nkword comword keyword nkwords words wordsnl
+ %type cmd simple first nexteq word nkword comword keyword nkwords words 
wordsnl
  %type NOT FOR IN WHILE IF TWIDDLE BANG SUBSHELL SWITCH FN BREAK
  %type WORD REDIR DUP PIPE
  %%
../rc.me5/syn.y:84,89 - syn.y:96,102
  | FN nkwords brace{$$=tree2(FN, $2, $3);}
  | FN nkwords  {$$=tree1(FN, $2);}
  simple:   first
+ | simple nexteq   {$$=tree2(ARGLIST, $1, $2);}
  | simple word {$$=tree2(ARGLIST, $1, $2);}
  | simple redir{$$=tree2(ARGLIST, $1, $2);}
  first:comword 
../rc.me5/syn.y:111,113 - syn.y:124,127
  | words word  {$$=tree2(WORDS, $1, $2);}
  nkwords:  {$$=(struct tree*)0;}
  | nkwords nkword  {$$=tree2(WORDS, $1, $2);}
+ nexteq:   word '=' word   {$$=treeeq('^', $1, $3);}

here are some test cases

; ./o.rc
broken! x=1 echo $x
1
broken! whatis zot
zot: not found
broken! zot=1 echo $zot
1
broken! whatis one
one: not found
broken! one=1 two=2 echo $one $two
1 2
broken! echo one=1
one=1
broken! echo if=1
if=1
broken! fn eq {echo one=1 two=2}
broken! eq
one=1 two=2

- erik

Re: [9fans] IPV6

[Erik Quanstrom]

nice.- erik

Re: [9fans] SHA-1 collision and venti

[erik quanstrom]

On Mon Feb 27 14:17:49 PST 2017, charles.fors...@gmail.com wrote:

> I think venti could deal with it: Rwrite returns a score, Tread provides a
> score, and the caller typically uses it as an opaque value. If not, whether
> a different sha1 is returned or a new algorithm is used, the caller could
> still not rely on sha1(block)=score.
> 
> In any case, fossil needs a fix to cope with venti returning "score
> collision", to prevent it failing to archive once it hits a shattered file,
> or rather the first venti-sized block of them.

i believe that rsc worked this out in some work he did based on venti.
sadly i don't remember the name of the project.

a modest proposal.  since p(collison) is calculated for a random collison,
why not just store encrypted blocks.

- erik

Re: [9fans] linux / p9p abomination

[erik quanstrom]

> while (true)
> if ($watch)
> while (!$cmd)
> $watch || true

rc allows empty conditionals, which are true.

- erik

Re: [9fans] Acme and Git

[Erik Quanstrom]

try writing the file?  On Feb 15, 2017 5:05 AM, Paul Lalonde  wrote:I know I'm not the only acme user who uses Git extensively :-)Is there some way to tell if a file is changed on disk that is open in an editor window?  I frequently change branches and I often find myself editing stale versions.  I notice when comes time to Put, but that's a bit late.Any tips to share? Paul

Re: [9fans] fail to crosscompile Rasperry Pi Miller's kernel

[erik quanstrom]

> Does any of you have any idea what could be the cause of the problem?
> The linker 5l in kencc does not support the -f linking option, but I think 
> none
> of the code in pool.c or libmemdraw use float/double at this point.
> Is there some important patches to 5l or 5c I am missing in kencc/? 

i think your source is out-of-sync:

 -f (5l only) Generate VFP hardware floating-point
 instructions.  Without this option, 5l generates
 arm7500 floating-point instructions which are emu-
 lated in the kernel.

i would imagine that your machine may have booted (the kernel does not use 
floating point),
but you can't see the screen.  if you set up a cpu server, there's a good 
chance it will be
accessable.

- erik

Re: [9fans] How to take a portion of a screenshot

[erik quanstrom]

On Wed Nov 23 13:50:02 PST 2016, jules.merit.eurocorp...@gmail.com wrote:


> I ported doom, after someone Runed plan9. Trying to get 9front Jurassic
> Park on MIPS r12k now.
> 
> Also plan9 clearly needs EEG for user defined scheduler and jukebox
> selection whilst in the labs.
> 

as soon as i saw the first "dnl", i gave up.

- erik

Re: [9fans] Auth server

[Erik Quanstrom]

well there are two benefits.  security of the keys and the ability to pxe boot the CPU server
On Oct 24, 2016 3:15 PM, G B  wrote:I've been reading and am in the process of planning a Plan 9 network with a terminal, a couple of CPU servers and a file server; I've read the authentication server can be separate from the CPU server.  Is there any benefit to separating them?  What steps would need to be taken to setup a separate auth server?

Re: [9fans] Terminal possibliities...

[Erik Quanstrom]

he he.  Puerto Toledo ftw!

Re: [9fans] The correct way to do an incorrect thing

[Erik Quanstrom]

a plan 9 thing would be to use /usr/$user/lib/acmebg and call it a day.
On Sep 28, 2016 4:07 PM, Marshall Conover  wrote:Hi all!As an awful person, I hacked rio's data.c to support backgrounds. Because the default code took a 1-by-1 pixel grey image and tiled it, I just shoved a line in there to load an image file instead using readimage(). (Hacked really is the appropriate word here.)My question is, would the plan9 approach to this (assuming this were a plan 9 thing to do in the first place) be to add a command line argument to rio that lets the user specify a file, or would it be to present some file somewhere the user can write a background to? E.g., `cat /usr/glenda/backgrounds/bg.bit > /rio/bg`.If there are any papers or man pages that'd be good to read for this question, I'd appreciate a finger in that direction.Thanks!mars

Re: [9fans] upas/send -r

[erik quanstrom]

On Fri Sep 23 18:40:00 PDT 2016, jules.merit.eurocorp...@gmail.com wrote:

> My cable company set my IP to my home address.  All sorts of MITM, spoofing.
> eurocorp.us (68.111.201.89) EscondidoCounty 1829
> There are 9fans in JadeHelm wargames.
> I'm James Jake Niantic, .dk Orphilla.
> (6:19)pm confirmed Erich, I ChKe
> 
> On Fri, Sep 23, 2016 at 6:19 PM, Erik Quanstrom <quans...@quanstro.net>
> wrote:
> 
> > that's an interesting topic.  I believe the best approach is to reject the
> > incoming connection.  the bypass mods are pretty good at rejecting bogus
> > sends by just enforcing RFC rules for helo.

the rfc only requires that the helo be a valid dns name.  so you would not be 
filtered
based on spoofing, but you would be filtered if you said you were 
machine.local, as
many windows boxes do by default.

- erik

Re: [9fans] upas/send -r

[Erik Quanstrom]

that's an interesting topic.  I believe the best approach is to reject the incoming connection.  the bypass mods are pretty good at rejecting bogus sends by just enforcing RFC rules for helo.
- erik

Re: [9fans] Is 9Fans dead or alive

[erik quanstrom]

On Thu Aug 25 17:41:51 PDT 2016, k...@westryn.net wrote:
> On Aug 24, 2016, at 7:54 AM, Nickolas Peter  
> wrote:
> > 
> > Brantley,
> > 
> > Wow, that's really impressive. Thanks for sharing. Would you say that 
> > Supermicro hardware supports Plan 9 well, or did it take a lot of hacking 
> > and driver development? I have a Supermicro 1U sitting in my uncles 
> > basement — I might go grab it and set it up as a fileserver.
> > 
> > Nick
> 
> Hello from a long time lurker on the list.  I am glad it is still alive.
> 
> I also find it exciting that Coraid lives again.  Well done, Brantley.

+1

- erik

Re: [9fans] vmware shared folders

[erik quanstrom]

On Sun Aug 28 01:58:51 PDT 2016, 9...@9netics.com wrote:
> > I also have the VMware code for plan9 from russ. he felt it is not enough 
> > time had passed to release it. VMware has changed over the years and the 
> > plan9 code needs to be updated.
> 
> a lot of the secret sauce code seems to be available now (LGPL license):
> 
> https://github.com/vmware/open-vm-tools/tree/master/open-vm-tools

just in time for vmware to be less relevant.  :-)

- erik

Re: [9fans] rio on plan 9 from user space

[Erik Quanstrom]

xnest is your friend!  one can run x within x, then run a new wm.  it's also possible to kill then restart your main wm.

Re: [9fans] Namespace inheritance between processes

[erik quanstrom]

> > Also, a totally random question: It seems like poor ergonomics that
> > one must create empty directories in order to serve as mount points.
> > Why not just allow mounting to names that don't exist yet?
> 
> mntgen(4)

linux has the same restriction, and no mntgen.  :-)

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

On Sat May 21 16:05:58 PDT 2016, 9...@9netics.com wrote:
> >> >> Waitmsg *exitsts = nil;
> 
> i see; it's set but not used before it is assigned to again.
> 
> i would expect the compiler to get the hint that it's initialization
> -- especially given that the value is 0 and the assignment is right
> with the declaration.

like i mentioned, gcc ignores variables that are set and not used, for
the most part.  i think behavior is odd.  there's nothing special about
assigning a simple type in a declaration.  

for example

char *s = nil;
and
char *s;

s = nil;

are equivalent.  gcc ignores both cases if they are not actually used.
one could add an automatic implicit USED in kenc by modifying
the doinit() in dcl.c, but i think that would be a mistake.  i find extra
assignments make it harder to read the code, as one has to consider
the assignment might be used when evaluating how a variable is used.

there are some exceptions to the general rule, for non simple types,
where the assignment may change the size.  and i'm gnoring some dark
corners of c99 like const int, which are not implemented in plan 9.

- erik

Re: [9fans] problem with acme on 9front

[erik quanstrom]

unfortunately, sam has hardcoded B into the command channel.
see /sys/src/cmd/samterm/plan9.c:/^plumbformat

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

> Yes, exactly.  And doesn't/didn't ndb have a tag that was used to indicate 
> whether a system or network used il?  (proto=il? I don't have access to a 
> 9labs machine to check at the moment.)
> 
> Determining ip6 connectivity shouldn't be that hard.  If you have a route, 
> you connect.  If you don't, the network stack does a fast ENOROUTE return and 
> the case falls through to the next address family.
> 
> IL is a bit trickier, since you can't know in advance if the destination 
> supports it, thus the ndb tags I'm vaguely remembering.  And if my memory is 
> correct, the fix for that would be to default 'supports IL' to no, if that's 
> not already the case.

cs uses hard-coded rules.  one could argue that it's up to dns to filter out
ip6, which would be straightforward one would only return ip6 when the
path from . to the zone in question is all ip6 accessible.  i realize this is
wrong, as the path to the dns server is not the same as the path of the
packets, but, you know, should be a better hurestic than we've got today.

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

On Sat May 21 15:19:06 PDT 2016, 9...@9netics.com wrote:
> > <   char exitsts[2*ERRMAX];
> > ---
> >>Waitmsg *exitsts = nil;
> > 
> > is likely to generate used-and-not-set on amd64.
> > 
> > - erik
> 
> i'm not sure i understand how. can you explain?

since the only code path that uses exitsts sets it unconditionally,
setting a declaration time is going to be optimized out.  when the
optimizer elides setting of a variable it emits the set and not used
diagnostic.

gcc doesn't do this with the usual flags, which is why it may be unexpected.
i've included a test program that makes this a little easier to read.
the test program emits the diagnostic "warning: warn.c:9 set and not used: s"

- erik

---
#include 
#include 

void
main(void)
{
char *s;

s = nil;
s = "xyz";
print("s=%s\n", s);
exits("");
}

Re: [9fans] bug in authdial()

[erik quanstrom]

also,

209c203
<   char exitsts[2*ERRMAX];
---
>   Waitmsg *exitsts = nil;

is likely to generate used-and-not-set on amd64.

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

On Sat May 21 14:47:24 PDT 2016, 9...@9netics.com wrote:
> > a better solution is to just use waitmsg (see wait(2)).  the parsing rules 
> > and sizing are
> > already implemented there.
> 
> yes, i agree. i changed my patch.

i believe this is missing a free.

- erik

Re: [9fans] 9front sam in plan9port.

[erik quanstrom]

On Sat May 21 11:32:04 PDT 2016, s...@9front.org wrote:
> > The plan9port version also has chording if in its samterm/main.c you
> > change #define chording 0 to #define chording 1.
> 
> It was also marked as being buggy, which is why it remains disabled by 
> default.

i believe rsc found the reason for this later.  the bug was that it caused 
protocol lock.
i don't recall what the details of the bug or the fix were.

- erik

Re: [9fans] Marvell Yukon 88E8055 NIC

[erik quanstrom]

On Wed May  4 23:51:49 PDT 2016, kokam...@hera.eonet.ne.jp wrote:
> I think this is written by eric, however, it may concern to others,
> and I'm now a 9front user.
> 
> I use Panasonic CF-R7 C2D notebook(maybe around 2009) which has 
> Yukon 88E8055 ether chip.  The etheryuk.c has no this entry.   
> Please add the entry of
>   0x11ab, 0x4363 1514 "88e8055"
> to vtab[].
> This chip works file!
> 
> Thank you eric!

great!  i never got much milage on this chipset.  it was a christmas project, 
and
was never in a product.

- erik

Re: [9fans] problem with acme on 9front

[erik quanstrom]

> This is tantamount to saying acme is superior because you are better at
> acme.  [...]

c'mon man.  you follow this with several paragraphs of opinion which appear
to say that acme is not better because you don't like it.

but then again, editors don't tend to lead to logical arguments.  :-)

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

On Fri May 20 15:27:56 PDT 2016, charles.fors...@gmail.com wrote:

> On 20 May 2016 at 23:04, Skip Tavakkolian <9...@9netics.com> wrote:
> 
> > i'm a little confused by the discussion of il + tcp on authdial
> > causing the delay.  if ndb/cs returns multiple dial strings, dialmulti
> > function (/sys/src/libc/9sys/dial.c) dials them all in parallel
> > (rfork) and the first one that returns, wins.
> >
> 
> 9front uses the original sequential one

so does 9atom.

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

On Fri May 20 21:48:40 PDT 2016, aris...@ar.aichi-u.ac.jp wrote:
> parallel dialing would be fine.
> I guess both cinap and erik have examined labs code.
> any problem with it?

i don't use this code.

i think the problem with parallel dial is that like the tricks we used to play 
in
nsec()—it assumes things about the calling environment.  for starters, it's 
going
to break anything that's already forking as it may eat wait messages.

it's been a while since i looked at this, but i think parallel dialing requires 
a
bit more of a rethink of the dialing code than just hacking in a fork.  without
restructuring the system, i think one would be forced into a dial device so that
any forking/threading could escape the current running environment.

the original problem this code was trying to solve was the fact that many 
connections
can't do ip6, and dialing ip6 slows down the connection quite a bit.

this problem is a little easier to fix.  cs needs to do a little more work to 
filter out
impossible connection types.  for example, if one's internet connection is not 
ip6
capable, then cs should be instructed to not return ip6 addresses.

- erik

Re: [9fans] bug in authdial()

[erik quanstrom]

> static int
> reap(Dest *dp)
> {
>   char exitsts[2*ERRMAX];
> + int n;
> - if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) {
> + if (outstandingprocs(dp) && (n = await(exitsts, sizeof exitsts-1)) >= 
> 0) {
> + exitsts[n] = 0;
>   notedeath(dp, exitsts);
>   return 0;
>   }
>   return -1;
> }
>
> probably 2*ERRMAX is enough for await().
> 
> I wonder why await() returns non-terminated string?
> 

a better solution is to just use waitmsg (see wait(2)).  the parsing rules and 
sizing are
already implemented there.

- erik

Re: [9fans] store NaN() to memory traps on 386 (387)

[erik quanstrom]

On Mon May  2 12:30:03 PDT 2016, rym...@gmail.com wrote:

> Not crash into a flaming ball of (very vague) fire?

the obvious loop with nan

for(i in `{seq nan >[2=]}){echo $i}

prints nothing, as the body is never executed.

what would you have it do?

to cinap's point, either nan -> float doesn't trap, and there is no protection
against bad fp math, or it does trap, and one has protection against producing
inadvertant nans.

by the way, the same issue exists with sse.

- erik

Re: [9fans] store NaN() to memory traps on 386 (387)

[erik quanstrom]

On Mon May  2 12:07:58 PDT 2016, cinap_len...@felloff.net wrote:
> 
> > file under: awk was really designed for pre-posix unix.  :-)
> 
> its not just about awk. whenever you want to convert a string to
> a floating point number under plan9 you'll have to deal with this
> problem:
> 
> cpu% seq nan
> seq 11791387: suicide: sys: fp: invalid operation fppc=0x2635 status=0x8081 
> pc=0x122f

that seems reasonable to me.  what could seq possibly do with nan?

- erik

Re: [9fans] store NaN() to memory traps on 386 (387)

[erik quanstrom]

> what sucks is that passing "nan" to strtod() will result in a program
> crash with the default fcr instead of rejecting the string. so everyone
> is forced to filter the inputs to strtod() to avoid the crash, or change
> the fcr and then deal with the nan's and infs.

file under: awk was really designed for pre-posix unix.  :-)

- erik

Re: [9fans] a script to update DNS root hints

[erik quanstrom]

interesting!  i took a different approach to this issue quite a while
ago, using dns/debug.  this approach should work assuming that it is
run often enough to prevent dropping of old ip addresses between runs.

- erik#!/bin/rc
rfork en

aserver=a.root-servers.net
letters=(a b c d e f g h i j k l m)

fn fatal {
echo $*>[1=2]
exit fatal
}

fn get{
ndb/dnsdebug @$aserver $* | awk '
$1=="answer" && $(NF-2) == "negative" {next}
$1=="answer" {printf "dom=%s%s=%s\n", $2, $(NF-1), $NF}
'
}

aserver = `{get a.root-servers.net|sed 's/.*=//g'}
if(~ $#aserver 0)
fatal cant find a.root-servers.net
{
echo '#'
echo '#  entries defining the dns root.  these will be overridden by 
any'
echo '#  authentic info obtained from the root.'
echo '#'
echo 'dom='
for(letter in $letters)
echo '  ns='^$letter^'.root-servers.net'
for(letter in $letters)
get $letter^.root-servers.net ip
{
for(letter in $letters){
get $letter^.root-servers.net ipv6
}
} | sed 's/^/# /g'
}

Re: [9fans] store NaN() to memory traps on 386 (387)

[erik quanstrom]

On Sat Apr 30 05:53:04 PDT 2016, cinap_len...@felloff.net wrote:
> with spews recent native awk port, we'v discovered an issue
> with strtod() that with the default FCR; which has FPINVALs
> traps enabled; the FMOVDP instruction that stores a NaN to memory
> traps. so it is not really possible to check for NaN result of
> strtod() unless you mask the traps.
> 
> The APE port of awk got away with strtod() not recognizing
> "nan" at all, while the native plan9 libc version does.
> 
> so the problem is that NaN() appears to be unusable with the
> default FCR on 387, and we'd like to have consistent behaviour
> under all archs when possible.
> 
> right now, the 387 seems to be the single oddball, so one idea
> was to have NaN() return a quiet NaN for 387 only instead of a
> signaling one.
> 
> On the other hand, one could argue that programs relying on
> NaN's have to explicitely disable FPINVAL traps on all archs.
> 
> Any suggestions on how to resolve this?

i'll assume the context here is on initial conversion from input to fields.
vaguely the rule is anything that's properly representable as a number, is a 
number,
and anything else is a string.  since awk is well older than ieee, nan, inf,
one could easily argue they should count as strings.

so in my mind, this isn't an issue.  my solution would be if the string is nan,
then don't bother calling strtod.

the gawk maintainers while complaining about posix 2004, evidently agree,
providing --posix to disable filtering out nan and other strings from being
passed to strtod.

- erik

Re: [9fans] OT: Ubiquitous data vs. Reality,

[erik quanstrom]

On Sun Apr  3 01:16:15 PDT 2016, 9f...@hamnavoe.com wrote:
> > If a member of Mensa (whose IQ must be at or above the 98th
> > percentile) can mistake social media for reaility, then that same
> > mistake can be (and most certainly is) made by the other 98% of the
> > population.
> 
> intelligence != wisdom
> 
> skill at solving IQ tests != intelligence

yup!

and, a 1000bhp engine on a yugo doesn't get much traction.  :-)

- erik

Re: [9fans] Plan 9 port to Raspberry Pi 3 Model B (ARM64)?

[erik quanstrom]

> 10-12 years ago FreeBSD had "project Evil" for an NDIS shim
> layer that allowed use of windows network drivers on FreeBSD.
> Has anyone considered writing a shim that allows use of a
> FreeBSD driver with plan9?

i looked at that a bit, and was not convinced that the surface area was 
manageable 

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

I saw this.  I'm not looking at the pcap file

On Feb 23, 2016 10:38 AM, hiro <23h...@gmail.com> wrote:
>
> i didn't see any out-of-window rx in the pcap. did i look the wrong way? 
>
>

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Tue Feb 23 09:52:28 PST 2016, 23h...@gmail.com wrote:
> which machine is in the west coast? the one your tracing on? is that
> hget or a web server on plan9? is this the same test as posted by
> david?
> 
> where do you see out-of-window rxes? what does that even mean?

this is from the same http://downloads.kergis.com/kertex/kertex_bundle.tar 
download as before.

an out-of-window rx is a rx packet that has no byte in the current window.
this can happen for legitimate reasons, but generally it does not.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Tue Feb 23 09:55:58 PST 2016, kennylevin...@gmail.com wrote:
> Just in case you want a another point of reference to eliminate weirdness 
> with the specific box: http://de.kl.wtf/f/10mburandom
> 
> Linode Arch Linux box in Frankfurt, serving you with a pretty standard usage 
> of Go’s http server. Should count as a “stock linux box with a non-weird HTTP 
> server”.
> 
> if you add an “s”, you get TLS. If you add a “0”, you get 100MB. If you 
> remove a country code, it goes through Cloudflare. You’ll have to guess where 
> to insert and remove those characters yourself, though!

10x better performance than kergis.com

0.094u 0.641s 48.016rhget -v http://de.kl.wtf/f/10mburandom

from the east coast with a non-residential uplink i get this very odd little 
wiggle

 ; time hget -v http://de.kl.wtf/f/10mburandom>/dev/null
1024 10485760
908553 10485760
2502873 10485760
2517473 10485760

unfortunately i don't have time to do more than putter today.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Tue Feb 23 09:25:53 PST 2016, 23h...@gmail.com wrote:
> in the long run the rwin seems much higher (65535) than the number of
> bytes in flight (less than 3x1500 bytes).
>
> i just noticed that the minimum latency numbers seem way low. many
> latency samples appear at around 40ms and 100ms, but there's also
> outliers? below 1ms. i don't get how this pcap got produced. perhaps
> wireshark is also interpreting it wrong, or timestamps are broken...

> > 26/status:Established qin 0 qout 0 rq 0.0 srtt 1256 mdev 628 sst 65535 cwin
> > 4517 swin 5808>>0 rwin 65535>>4 qscale 0 timer.start 10 timer.count 10
> > rerecv 0 katimer.start 2400 katimer.count 2400
> 
> where did you run this?

machine on the us west coast.  clearly we are prevoking some sort of odd 
behavior
in this machine, but it's not clear to me what we're doing.

the only clue we have is the out-of-window rxes.  perhaps the sender is scaling.

- erik

Re: [9fans] Go: FP in note handler

[erik quanstrom]

On Tue Feb 23 07:55:26 PST 2016, kennylevin...@gmail.com wrote:
> A benchmark was supposedly made of the new duffcopy/duffzero which claimed 
> significant speedup for larger copies: 
> https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da
> 
> I have no clue whether this holds true or not. My intention to reenable 
> duffcopy and continue to use duffzero is mostly to avoid differences and 
> ensure that the note handlers are floating point free in the future. Whether 
> the duffcopy/duffzero’s current form is an actual optimization or just a 
> complexity, I cannot say. A test was made in #cat-v out of annoyance where 
> the result seemed to be that it was indeed faster to use MOVUPS, but I don’t 
> remember the details.

that post is a speedup relative to the original asm, which might not be as good 
as the best
non-sse versions, and it is also for amd64.

- erik

Re: [9fans] Go: FP in note handler

[erik quanstrom]

On Tue Feb 23 02:36:41 PST 2016, kennylevin...@gmail.com wrote:
> Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 
> specific runtime.sighandler implementation and everything called by it 
> directly. Notes that don't exit the process are queued and should run outside 
> the actual note handler.
> 
> I think the "magic" code will be isolated, and might fend off accidental 
> future additions of floating point registers. The magic-ness also only 
> revolves around avoiding duffzero and duffcopy in some way. I also think that 
> removing conditionals in the compiler will be a positive thing.
> 
> I still do not know the feasibility of my plan, whether it is possible to do 
> cleanly, or possible at all. Maybe someone smarter than me with knowledge on 
> the matter could chime in and call me an idiot?
> 
> Avoiding duffcopy should be easy with a simple memmove implementation. If 
> done right, we can also remove the plan9 specific runtime.memmove and only 
> use the slow memmove in sighandler (The globlal runtime.memmove is 
> implemented using MOVUPS just like duffcopy. Duffcopy is used for blockcopies 
> by the compiler in some cases, although I must admit to not know all the 
> cases yet).
> 
> Avoiding duffzero without compiler assistance is a bit more tricky - global 
> variables, stack on assembly functions, something like that.

fwiw, on modern amd64 machines, using the xmm and ymm registers has a benefit 
only in a narrow range
of sizes (384-511 bytes) and a subset of (mis-)alignments that i've forgotten.  
at least for the exact test setup
i used on 3-4 different µarches.  intel claims rep; movs is the 
(architecturally) fastest way to go.

i am not sure any of this makes much difference, as it's hard to know what a 
real-world memory
access pattern looks like, and that seems to dominate all but gigantic moves, 
for which rep; movs
is actually no slower than even the trickiest use of ymm registers.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Tue Feb 23 04:49:55 PST 2016, 23h...@gmail.com wrote:
> i just realized the http *response* packets all have their rwin set to
> 5808 only, while the other side has the former described behavior
> hovering around 65535.
> perhaps the http server does no window scaling?!

26/status:Established qin 0 qout 0 rq 0.0 srtt 1256 mdev 628 sst 65535 cwin 
4517 swin 5808>>0 rwin 65535>>4 qscale 0 timer.start 10 timer.count 10 rerecv 0 
katimer.start 2400 katimer.count 2400

yes.  but as we're sending nothing, we can ack into an empty window.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Tue Feb 23 04:32:50 PST 2016, 23h...@gmail.com wrote:
> erik: I don't think nowadays we need to limit rwin unless we
> artificially want to reduce the bandwidth (e.g. in my torrent program,
> or an rsync that's running in the background and shouldn't use up the
> whole bandwidth of the slow DSL uplink).
> in the past it seems to have been used to combat memory limitations of
> the receiver. but nowadays we have enough memory, so in normal
> operation rwin should always be fully open.

we're not.  we're advertizing 65535<<4, as noted earlier.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Tue Feb 23 04:39:42 PST 2016, 23h...@gmail.com wrote:
> in any case we seem limited by congestion window, not rwin.

can you explain?

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Mon Feb 22 07:29:56 PST 2016, tlaro...@polynum.com wrote:
> On Mon, Feb 22, 2016 at 10:21:02AM -0500, stanley lieber wrote:
> > Have you tried setting and alternate user agent?
> > 
> 
> No. Is it possible to change the string for hget?

that's been ruled out, i think, by david.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Mon Feb 22 05:41:31 PST 2016, 0in...@gmail.com wrote:
> This issue seems more related to Plan 9 than hget.
> 
> On Linux :
> 
> $ time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
> 
> real0m1.783s
> user0m0.037s
> sys 0m0.046s
> 
> On 9vx:
> 
> % time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
> couldn't set mtime: permission denied
> 0.00u 0.00s 1.93r hget -o /dev/null
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> 
> On Plan 9:
> 
> % time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
> couldn't set mtime: permission denied
> 0.02u 0.01s 37.95r hget -o /dev/null
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> 

i noticed this message:

tcp: trim: !inwind: seq 3582371632-3582373071 win 3582374512-3582440046 l 1440 
from 213.186.33.4

i'll need to do a detailed analysis of this to figure out what's going on here.
this could be something that tcpdump, or snoopy could make kind of obvious.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

why?  what's the evidence?

- erik


On Feb 22, 2016 5:02 AM, tlaro...@polynum.com wrote:
>
> On Mon, Feb 22, 2016 at 01:52:48PM +0100, Mark van Atten wrote: 
> > Same 9front under virtualbox: 
> > 
> > term% time hget -o /dev/null http://mirrors.ctan.org/macros/latex/base.zip 
> > 0.06u 0.24s 8.74r hget -o /dev/null 
> > http://mirrors.ctan.org/macros/latex/base.zip 
>
> Yes, this is the problem. It is this very address: kergis.com that is 
> causing a problem. The question is: is it because of something in the 
> Plan9 implementation; or is it a different behavior from the http server 
> depending on the OS/utility advertised? I suspect more the latter. 
> -- 
>     Thierry Laronde  
>  http://www.kergis.com/ 
>  http://www.arts-po.fr/ 
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C 
>
>

Re: [9fans] file descriptor leak

[erik quanstrom]

On Tue Feb 16 13:19:29 PST 2016, charles.fors...@gmail.com wrote:

> On 16 February 2016 at 18:01,  wrote:
> 
> > and the parent proc doesnt need the fd to /dev/null, it could as well just
> > open it in the child like:
> >
> > close(0); open("/dev/null", OREAD);
> >
> >
> There's no harm in making and using a more general function, even in a
> specific way, so that part's ok.
> The caller just needs to play its part properly.
> 
> after spending 5 minutes writing the code fixing all these issues mentiond
> > above, i'll just throw it all away and delete the whole remounting logic
> > for /net.alt in 9front.
> 
> 
> It's often better to use the Erlang fail-fast ("just fail") and restart
> approach for persistent services.
> 
> More important would be to look at /proc/N/fd on a failing system.
> I've a feeling that the system/outside stuff isn't actually the problem,
> since I've seen the diagnostic on a system that wasn't using /net.alt.
> In that case, the problem (as I remember it) was that an Internet link
> further on was down,
> so no messages got through to remote DNS, and file descriptors were
> building up in slave processes
> waiting for replies on /net/udp. Once the link was up, it went back to
> normal.

we saw this a lot at coraid, but never did catch a smoking-gun process.
i don't recall a perfect correlation to internet down.

- erik

Re: [9fans] rc exec error behaviour

[erik quanstrom]

On Sat Jan 30 08:33:54 PST 2016, cinap_len...@felloff.net wrote:
> in the rc shell, when one has exec statement and the exec fails, rc tries to
> continue interpreting statements after the exec which fails with a strange
> EOF error because in the process of preparing filedescriptors for exec,
> the very fd thats used to read the script was closed.
> 
> burnzez provided an example of this like:
> 
> term% rc -c 'exec doesnotexist; echo test'
> doesnotexist: './doesnotexist' directory entry not found
> test
> rc: /rc/lib/rcmain:29: token EOF: syntax error
> 
> the manpage does not explicitely specify what should happen when exec fails.
> 
> i did try to have rc open the . script as OCEXEC and that fixed the
> problem, but it wont work for any other redirections and will have side 
> effects
> as the close-on-exec flag is a propery of the channel and not of the file
> descriptor slot. so imagine stuff like . /fd/0...
> 
> i think it would me most resonable to just have rc exit with error status on
> failure. are there any objections to this?

i don't think that's the right thing to do.  i think the specification is 
reasonable,
and what i'd like the shell to do on exec failure.  i have a little hack that 
shows
it's feasable to recover, although i think the approach i'm taking really 
sucks.  :-)

; 6.out
broken! exec x
undoableredir: close 3 /rc/lib/rcmain 512
undoableredir: close 4 /dev/cons 1076
x: '/bin/x' directory entry not found
exec fails
undoredir: open /rc/lib/rcmain → 3
undoredir: seek 512 /rc/lib/rcmain
undoredir: open /dev/cons → 4
undoredir: seek 1076 /dev/cons

unfortunately, this depends on fd2path which doesn't know the open
mode of the file in question.  (so wierd, why doesn't it?)  but /proc/$pid/fd
knows all about it.  :-)

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

> > anyway, please update your tcp.  the debugging tools that are most
> > helpful with tcp are
> > /net/tcp/stats
> > /net/tcp/*/status
> > echo tcp>/net/log && tail -f /net/log
> 
> To update I need to update the sources. Where are now the "updated"
> sources? since Bell Labs site seems to be definitively down... Is there
> somewhere the "latest" sources, at least with the TCP corrections?

i think that david has a mirror up, and 9fs sources still works here.

you can also grab the 9atom version @ 
http://sources.9atom.org/sys/src/9/ip/tcp.c
contact me off-list about any compile issues.  a few greps don't show any of 
the usual suspects, but i haven't tried myself.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

> > anyway, please update your tcp.  the debugging tools that are most
> > helpful with tcp are
> > /net/tcp/stats
> > /net/tcp/*/status
> > echo tcp>/net/log && tail -f /net/log
> 
> We have definitively not the same systems ;-) The echo tcp brings an
> error for netlog.

sorry, it's "echo tcp set>/net/log && tail -f /net/log".

chasing the performance of different sites is what lead to the tcp improvements.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Sat Feb 20 06:04:02 PST 2016, tlaro...@polynum.com wrote:
> On Sat, Feb 20, 2016 at 02:31:54PM +0100, hiro wrote:
> > what is the latency on WAN?
> 
> When using traceroute, I have 42.6ms for a roundtrip 
> (cf. with LAN: 0.23ms).
> 
> But the very same machine, under NetBSD, with the very same ip address,
> downloads the very same file from the very same external server
> (downloads.kergis.com) in 17s, while hget(1) spends 6 minutes doing
> it.
> 
> I wondered if the unsupported same chip integrated network card would
> be a problem. But disabling it via the BIOS doesn't change anything.
> 
> Is there a way to trace what hget is doing/calling so that I can have a
> clue about the bottleneck? There is no transmission errors on the
> interface, so the problem is in the upper levels of TCP/IP.

yes.  i believe this was suggested before.  from the evidence, the best
guess is that you are using an old kernel with an old tcp.

the old tcp had abysmal performance starting at a latency of ~10ms.  this
was due to a flawed implementation of tcp reno.  plan 9 used to commit
the cardinal sin of tcp, and move the left edge of the window.

anyway, please update your tcp.  the debugging tools that are most
helpful with tcp are
/net/tcp/stats
/net/tcp/*/status
echo tcp>/net/log && tail -f /net/log

- erik

Re: [9fans] NetSurf (browser) and Duktape (javascript)

[erik quanstrom]

> What would be really cool is if  the LibNSFB (netsurf framebuffer

not safe for b... business?

- erik

Re: [9fans] NetSurf (browser) and Duktape (javascript)

[erik quanstrom]

> NetSurf will incorporate Duktape javascript engine. Does Mothra have
> javascript?

no.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

> Is /dev/irqstat a lapsus? Here are /dev/irqalloc and
> /net/ether0/ifstats:
[...]
>  42  10 ether0

well, boo.  the labs version doesn't give enough information.  i was expecting
something like
; grep ether0 /dev/irqalloc
   65.0  11 17224065 190397006374 msi-x
ether0
which gives vector.processor, bus irq, number of interrupts, total fastticks 
taken, type, and driver.
with this info, one can calculate ns/interrupt and interrupts/sec.

> TxOk: 4483
> RxOk: 7520
[..]
> xmit descr queue len: highwater 0/31 curr 0 hitmax 0

this doesn't look like very much traffic.  how did you test?  are you using
the latest tcp?  what is the ping latency?  older labs kernels did a poor job
with moderate latency, and any packet loss.  newer versions should be ok,
but i haven't tested myself.

> rtl8169: unknown mac 8168 4c00

my version of the driver handles this hardware

> i8042: fe returned to the ea command

you don't have a ps2 mouse, but the system is configured to expect one.
0xea -> set streaming.

- erik

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

the standard labs driver checks the speed during auto negotiation.
so it is often wrong.

- erik


On Feb 18, 2016 3:41 PM, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
>
> hello, 
>
> rtl8169 is popular in cheap MB, so it is installed in my many MBs. 
> however, cat /dev/kmesg claims: 
> rtl8169: oui 0x732 phyno 1, macv = 0x3c00 phyv = 0x0002 
> #l0: rtl8169: 100Mbps port 0xD000 irq 10: 001fd0169891 
>
> the “100Mbps" in the message is correct or not? 
>
> I also feel rtl8169 is slow, so I replace on-board rtl8169 by intel’s card  
> if possible. 
>
>
>
> > 2016/02/18 22:22、erik quanstrom <quans...@quanstro.net> のメール： 
> > 
> > the 8169 driver is pretty fast.  I've measured it at more than 500mbps. 
> > it sounds like something else is misbehaving.  what does 
> > /dev/irqstat say.  I bet something is stuck. 
> > 
> > - erik 
> > 
> > 
> > On Feb 18, 2016 3:30 AM, tlaro...@polynum.com wrote: 
> >> 
> >> Hello, 
> >> 
> >> I have finally managed to install plan9 on my new workstation. 
> >> 
> >> By putting back the keyboard on the PS2 connector, I have solved some 
> >> unfelicities (with the USB->legacy emulation, the keyboard switched 
> >> every other typing to UPPERCASE...). 
> >> 
> >> The mouse, still USB connected and hence "emulated" by the BIOS, 
> >> does not react very gracefully but I will see if I can play with 
> >> the acceleration and the resolution to have a better terminal. (Or 
> >> if I manage to find a long enough cable to have a COM slot back since 
> >> there is the bare connector on the motherboard; in this case I will go 
> >> back to a com mouse and will be able to probe USB for other 
> >> devices---external disks.) 
> >> 
> >> One thing is inconvenient: I have a rtl8169 gbe pci-e ether card, but 
> >> when testing the compilation of kerTeX (it has been fixed: it works for 
> >> the last release; rio to come for METAFONT), the throughput with hget is 
> >> abysmal: 30kB/s... The disk is not a fault, reacting well enough (I have 
> >> plenty of RAM and the blocks cache for fossil is set to 3000---it could 
> >> be obviously higher). 
> >> 
> >> Setting the mtu to jumbo packet does not help. 
> >> 
> >> Is there something to tune or is it simply that the chip is not well 
> >> supported? 
> >> 
> >> TIA 
> >> -- 
> >> Thierry Laronde  
> >>  http://www.kergis.com/ 
> >>  http://www.arts-po.fr/ 
> >> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C 
> >> 
> >> 
>
>
>

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

the 8169 driver is pretty fast.  I've measured it at more than 500mbps.
it sounds like something else is misbehaving.  what does
/dev/irqstat say.  I bet something is stuck.

- erik


On Feb 18, 2016 3:30 AM, tlaro...@polynum.com wrote:
>
> Hello, 
>
> I have finally managed to install plan9 on my new workstation. 
>
> By putting back the keyboard on the PS2 connector, I have solved some 
> unfelicities (with the USB->legacy emulation, the keyboard switched 
> every other typing to UPPERCASE...). 
>
> The mouse, still USB connected and hence "emulated" by the BIOS, 
> does not react very gracefully but I will see if I can play with 
> the acceleration and the resolution to have a better terminal. (Or 
> if I manage to find a long enough cable to have a COM slot back since 
> there is the bare connector on the motherboard; in this case I will go 
> back to a com mouse and will be able to probe USB for other 
> devices---external disks.) 
>
> One thing is inconvenient: I have a rtl8169 gbe pci-e ether card, but 
> when testing the compilation of kerTeX (it has been fixed: it works for 
> the last release; rio to come for METAFONT), the throughput with hget is 
> abysmal: 30kB/s... The disk is not a fault, reacting well enough (I have 
> plenty of RAM and the blocks cache for fossil is set to 3000---it could 
> be obviously higher). 
>
> Setting the mtu to jumbo packet does not help. 
>
> Is there something to tune or is it simply that the chip is not well 
> supported? 
>
> TIA 
> -- 
>     Thierry Laronde  
>  http://www.kergis.com/ 
>  http://www.arts-po.fr/ 
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C 
>
>

Re: [9fans] file descriptor leak

[erik quanstrom]

> limitation on the number of processes that can be queued on a qlock()?

in user space, yes.

- erik

Re: [9fans] plan9.ini: ipconfig and bootargs

[erik quanstrom]

On Sun Feb 14 08:30:20 PST 2016, tlaro...@polynum.com wrote:
> Hello,
> 
> When trying to re-install a Plan9 on a new node, being unable, with the
> kernel compiled present on the CDROM image, to access a FAT or an iso
> image of a root file system, I went to a combination of a minimal sketch
> of a plan9 slice, with a 9fat made "by hand" (from an already installed
> other OS---here NetBSD) and access at boot time a remote root
> filesystem, for the installation, serves by another Unix node serving
> 9P2000.
> 
> The surprise is with the bootargs, in plan9.ini, supposed to configure
> the network for the node, in order to access a remote root filesystem,
> as in:
> 
> fs=192.168.1.3
> # auth not used
> auth=192.168.1.3
> bootargs=tcp!-g 192.168.1.1 gbe 192.168.1.2 255.255.255.0
> 
> what is after the '!' being supposed to be args to ip/ipconfig.

here's what i have on my cpu server

nobootprompt=il -g 10.1.10.1 ether /net/ether0 10.1.1.1 /112

nobootprompt is equivalent to bootargs

- erik

Re: [9fans] bug in exportfs

[erik quanstrom]

> My point was that under the circumstances we are stuck with people who
> DO use the leading dot to make files disappear from directory listings
> and they won't budge :-)

what the intent of the leading dot might be is not recorded in the file system 
and
one can ignore the convention as one wishes, with no impact to any other user.
i don't remember the last time i've hidden dot files from myself by using only
the standard options on a unix-y system.

- erik

Re: [9fans] bug in exportfs

[erik quanstrom]

> Yes, although that convention isn't in Plan 9, and it might be worthwhile
> reconsidering how and why it is used.
> If for configuration files, perhaps they should be stored elsewhere; if for
> access control (eg, .htaccess), perhaps
> groups would be better, with dynamic group membership providing the effect
> of an access control list.

sadly among its other sins, the plan 9 webserver does use .httplogin

- erik

Re: [9fans] bug in exportfs

[erik quanstrom]

On Mon Feb 15 07:08:06 PST 2016, lu...@proxima.alt.za wrote:
> > Ah, my memory fails me, mostly due to too much time on Unipress machines in 
> > the 1980's. 
> 
> Rob's explanation for how the hidden files came about is out there in the 
> wild.  I recall enjoying it. Probably one of Rob Pike's blog entries or 
> somesuch on his own web site.

https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp

- erik

Re: [9fans] BCD encoding in Plan9 - don't shoot me

[erik quanstrom]

> So, I'm working with ISO8583,  a "standard" (HAHAHAH!)  The "standard"
> allows  but does not require, BCD encoding of numerical data. Which may or
> may not have a BCD-encoded numerical length prefix. The prefix may or may
> not be 1 to 3 bytes in length. Or the data might come with no prefix, and
> be right justified in a fixed width field of known size. Or left justified.
> So hard to tell these days.
> 
> But I ramble. So I was just wanting to ask if anyone here has any simple
> BCD conversion routines.
> 
> But, actually, ignore the subject line. Just shoot me.

/sys/src/9/pc/devrtc.c has an example of simple conversions, but given that 
standard,
i suppose simple is not what you're after.

- erik

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

> I think too much depends on the perception of a need to use assembly.
> If you start from the assumption that assembly can be relegated to
> pin-point optimisation on one hand and architecture-focused
> instructions on the other, that leaves a huge space in the middle
> where one can use a more human notation to represent abstractions.
> 
> But when you cannot escape needing to use architecture-dependent
> coding for abstract concepts, the battle is irreversibly lost.  Even,

splhi(), and splx() (see splhi(9), which enable and disable interrupts, are
abstract concepts that are neither optimization, nor are able to be expressed
in c.  there is no harm done by this pattern.  it simply is the way things are.

- erik

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

> Or just how some architectures use typed registers, and some use
> different-sized instruction variants.

which architeture uses typed registers?  a quick check of 386, 68020,
alpha, arm, mips, power, power64, sparc, and amd64 shows all use
MOV[WLQ].

- erik

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

> I still quite like the distribution of work, for the reasons Aram just gave.
> Latterly, I've been making the things a little smaller and perhaps simpler,
> by continuing some changes that
> Russ made (eg, pgen.c pswt.c) to reduce the amount of almost identical code
> that's replicated across the suites.

thanks for that!

- erik

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

> > MOVQQU or MOVQQA still follow the expected pattern.
> > 
> 
> Originally on amd64 I consistently used O instead of sometimes DQ and
> sometimes O as Intel did, but in the end I changed them back to the
> Intel names, since it was hard to look them up, and there were so
> many.

ack.  typo in my post.  :-(.  it's too bad about DQ rather than O, but the
reasons make perfect sense.

- erik

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

On Tue Feb  2 08:43:47 PST 2016, sstall...@gmail.com wrote:
> Hi Giacomo,
> 
> It's probably worth mentioning that learning assembly using the Plan 9
> assembler is probably a bad idea. *a makes heavy use of pseudo
> instructions and registers and unless you're well versed in its
> quirks, can be very confusing when looking at more common assembly
> dialects. Many instructions are directly encoded in the instruction
> stream, largely due to the fact that it is more difficult than it
> should be to extend the assembler as architectures evolve*. More
> mechanically, Plan 9 makes use of a loader, which causes a number of
> operations you would expect to be present in the assembler to be
> deferred until later.

hi, steve!

i've found the plan 9 assemblers to be straight-forward enough.  i love
the consistency from one architecture to another.  i like the fact that
there are so few meta-directives, and i do like the fact that the linker
will do the obvious rearrangments of plan 9 assembly, including automatic
delay slot filling, and other such fiddly bits.

obviously, this is just an opinion, so ymmv.

i think this is off the original point, but as to modifying the assmbler.
to add a new instruction, the linker, assembler and libmach need modification.
typically this is a matter of adding a line to each one for assembly, linking,
and disassembly, respecively.  it's worth looking at the addition of the ymm,
and then zmm registers and those patterns to 6[al] and libmach.  this is an
example of adding a new instruction encoding to an existing arch.

> * The diff to update support for ARMv7-A to 5a came in at over 2800
> lines; this was to add a handful of instructions.

do you perhaps mean the linker?

the pi kernels, which supports v6 (original) and v7 (pi2) rely on small asm
files for arch-specific functions.  i think you provided some explaination of
why this approach would not work for v5, but unfortunately, i don't remember
it.

- erik