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

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

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

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

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

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

Re: [9fans] Understanding /dev/draw

nt 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

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

Re: [9fans] Rc port.

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

Re: [9fans] Rc port.

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

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

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

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

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

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

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

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

> 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

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

> > 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 >

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

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

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

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!)

> 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

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

> 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

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

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

Re: [9fans] nupas

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

Re: [9fans] There is no fork

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

Re: [9fans] SCMs

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

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

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

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

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

Re: [9fans] Spectre and Meltdown

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

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

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

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:/**

Re: [9fans] equality sign in Rc

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

Re: [9fans] equality sign in Rc

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

Re: [9fans] equality sign in Rc

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.perha

Re: [9fans] equality sign in Rc

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

Re: [9fans] equality sign in Rc

> 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

Re: [9fans] equality sign in Rc

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

Re: [9fans] IPV6

nice.- erik

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

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

Re: [9fans] linux / p9p abomination

> while (true) > if ($watch) > while (!$cmd) > $watch || true rc allows empty conditionals, which are true. - erik

Re: [9fans] Acme and Git

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

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

> 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/?

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

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

Re: [9fans] Auth server

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

Re: [9fans] Terminal possibliities...

he he.  Puerto Toledo ftw!

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

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

Re: [9fans] upas/send -r

. > (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 re

Re: [9fans] upas/send -r

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

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

Re: [9fans] vmware shared folders

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

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

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

> > 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()

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

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

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

Re: [9fans] bug in authdial()

> 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

Re: [9fans] bug in authdial()

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

Re: [9fans] bug in authdial()

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()

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.

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

Re: [9fans] Marvell Yukon 88E8055 NIC

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.

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

> 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. :-) -

Re: [9fans] bug in authdial()

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

Re: [9fans] bug in authdial()

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

Re: [9fans] bug in authdial()

> 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; >

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

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

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

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

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

> 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

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

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

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

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

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

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

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

> 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

Re: [9fans] rtl8169 gbe slow

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

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

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

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

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

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 >

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

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

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] file descriptor leak

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); > > > >

Re: [9fans] rc exec error behaviour

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, >

Re: [9fans] rtl8169 gbe slow

> > 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

Re: [9fans] rtl8169 gbe slow

> > 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

Re: [9fans] rtl8169 gbe slow

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

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

> What would be really cool is if the LibNSFB (netsurf framebuffer not safe for b... business? - erik

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

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

Re: [9fans] rtl8169 gbe slow

> 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

Re: [9fans] rtl8169 gbe slow

sg 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 possi

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] file descriptor leak

> 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

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

Re: [9fans] bug in exportfs

> 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

Re: [9fans] bug in exportfs

> 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

Re: [9fans] bug in exportfs

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

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

> 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

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

> 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

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

> 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

> 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

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

> > 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

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

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

  1   2   3   4   5   6   7   8   9   10   >