Re: [9fans] MIPS-64
Yes I started on working the toolchain a couple years ago, based on some earlier work done at the labs. Development stalled due to other work at the time and I never got back to it. But it's on sources (tim/4acl.tgz) if anybody wants to pick it up. I'm happy to provide any help. tim > tim weiss started work on kencc mips64 port and I started (w/o the > compiler) playing with Plan 9 on mips64 based on the old carrera port. > > the stupid initial code is at http://src.oitobits.net/9sgi > > On Thu, Mar 19, 2009 at 8:24 PM, ron minnich wrote: >> On Thu, Mar 19, 2009 at 4:14 PM, Anthony Sorace wrote: >>> i was looking at this a week or two ago, trying to find an ARM or MIPS >>> laptop to play with. my first question was whether the "missing" parts >>> of the MIPS instruction set are things that our compilers currently >>> generate; SoC (oh, and my day job) ramped up before i could find the >>> list of missing instructions. any idea? >>> >>> getting quotes or delivery in the US seemed tricky, too. >> >> so, here's a silghtly controversial (maybe) suggestion. Maybe my >> memory is wrong, but i believe the vx32 kernel is gcc-compiled. There >> is gcc for this CPU. It might be easier to start from the vx32 kernel >> and gcc to target this machine, rather than do a 64-bit MIPS port of >> the plan 9 C compiler. Or not: a few of the folks on this list could >> probably retarget in very short order (I'm not one of the,however). >> >> ron >> >> > > > > -- > iru
Re: [9fans] has anyone used xmonad?
> i stumbled upon this the other day. xmonad is a tiling window manager > written in haskell that looks similar to acme, although it can be > completely keyboard-driven. if anyone has used it please comment on > it. I use it as my X WM. So far I've been pretty satisfied with it. By default you can't tweak the size of a window within a column of mutliple windows, but there is an extension in the contrib package which will do this. It works well with dual monitors. I've been planning to add some code to the config (or an extension) to allow certain things to be driven by the mouse. I haven't done this yet but it appears doable.
Re: [9fans] apropos of the glendix post
> That said, how do we mobilise the community to focus on useful > drivers? I suppose we start with Ron's wish list, then we explore > Russ' partially complete postings (i386 emulation, Centrino drivers, > I'm sure I've forgotten many more) and thirdly we post a list of > willing contributors, possibly split into code writers and advisors. Are you serious? I have a crazy idea: how about you actually write one?
Re: [9fans] 9vx vs drawterm
>> The advantage of 9vx over drawterm, for me, is that 9vx >> doesn't require a cpu server. > > You are not using Plan 9 anymore then, rather you are using something > similar to Plan 9. > > I felt that Plan 9 is abused by 9vx, which I felt at first glance, but > at that time I didn't want to say this... > > I prefer drawterm because it stands in the Plan 9 world. While I haven't yet gotten the chance to play with it, personally I felt 9vx is really a normal P9 terminal, whereas drawterm is not. Because it doesn't run natively makes no difference.
Re: [9fans] 9vx on OpenBSD-4.3
> On Mon, Jun 30, 2008 at 3:04 PM, Tim Wiess <[EMAIL PROTECTED]> wrote: >> If you can wait a couple days I'll have some time later in the >> week to port this over to OpenBSD. >> >> >>> I'm currently trying to get 9vx work on OpenBSD-4.3 (i386, 750Mhz, >>> 256MB RAM), but each time I want to start 9vx I get the following: >>> >>> $ ./9vx.FreeBSD -u glenda >>> Abort Trap >>> $ >>> >>> Of course FreeBSD Binary Emulation has been turned on using >>> /etc/sysctl.conf. >>> >>> Furthermore I tried also to use the Linux binary (using the Linux >>> Emulation, which I also switched on), but I get the same message back >>> in this case too. >>> >>> If you need some more informations about the system, drop me a line. >>> >>> Any hints how to solve this problem welcome >>> >>> Thanks, >>> Malik > > I started the porting some days ago. Seems the only missing part is > one bit in i386_set_ldt. > I can upload it somewhere if anyone want to play with the missing stuff. Ok cool. I'd be happy to look at it when I get the chance.
Re: [9fans] 9vx on OpenBSD-4.3
If you can wait a couple days I'll have some time later in the week to port this over to OpenBSD. > I'm currently trying to get 9vx work on OpenBSD-4.3 (i386, 750Mhz, > 256MB RAM), but each time I want to start 9vx I get the following: > > $ ./9vx.FreeBSD -u glenda > Abort Trap > $ > > Of course FreeBSD Binary Emulation has been turned on using /etc/sysctl.conf. > > Furthermore I tried also to use the Linux binary (using the Linux > Emulation, which I also switched on), but I get the same message back > in this case too. > > If you need some more informations about the system, drop me a line. > > Any hints how to solve this problem welcome > > Thanks, > Malik
Re: [9fans] sad commentary
>> this slashdot article almost asks for cpu >> functionality for plan 9 by name. >> >> http://ask.slashdot.org/askslashdot/08/06/29/1417247.shtml >> >> not a single mention of plan 9. i hope >> this is an indication that slashdot has >> slipped. >> >> screens? 1978 called and wants its >> terminal server mentality back. >> >> - erik > > cpu is not persistent, at least not in the way > he wants it. Yeah, seems like the poster is more interested in something similar to what Octopus give you.
Re: [9fans] telnet vs. godaddy whois
>> rfc 742 p. 42 says >> >> [...] If the the user signals a push function then the >> data must be sent even if it is a small segment. >> >> by "illegal" i mean goes contrary to an rfc "must." perhaps >> i'm missing something. > > i don't see how what was sent is contrary to that requirement. > >>sensible as setting PSH on a pure ACK. > > i don't understand this reference to a `pure' ACK. it's an ACK! in TCP/IP > every > packet after SYN must have an ACK (or that really is -- explicitly -- > illegal). > the ACK and PSH have nothing to do with each other. > in fact, the receiver isn't handling the PSH oddly because it's associated > with an ACK, but because it misinterpreted the standard, or the standard > isn't clear. By pure I assume he meant an ACK with no data, which is what I also meant by "plain ACK". But I agree with Charles here. After going back over the related sections of the RFC I don't see how this behavior violates anything in the standard. It's just not very common, and obviously not interpreted very well by this particular endpoint. Has anybody ever experienced this problem before with any of there P9 systems? I haven't.
Re: [9fans] telnet vs. godaddy whois
>> what's the definition of `wrong' here? >> Meaning that the patch Eric proposed is probably the better way to >> deal with ACKs. It wasn't meant to be taken too literally though, >> hence the "I think". > > what's the definition of `better' here? > > well, i won't persist in pedantry. i was just curious about the rationale for > the > adjectives. i'd say it isn't really to do with ACKs: the protocol definition > rightly > has ACK and PSH interpreted by different sides at the destination: input for > ACK and output for PSH. > in fact, the Plan 9 behaviour is rational for a sluggish or zero window: the > receiving side might > delay delivering data to the application until a PSH, but won't open the > window if that queue is full. > (thus rfc1122 mutters about deadlock in the absence of PSH, in 4.2.2.2.) My rationale was the section of the rfc that Eric quoted with his patch, which seemed to address my earlier suspicions. But I just went back over that section and realize that I misinterperted that quote a little. So I don't believe that P9's behavior is "wrong" in the sense that's it's violating any assumptions in the rfc. It is (I think) the first time I've seen PSH being set on a plain ACK, but I do understand your argument.
Re: [9fans] telnet vs. godaddy whois
>> I noticed this some time ago when I was doing some work in the >> stack and thought it was very questionable. But I never got a >> chance to go back and do further research. Nevertheless I think >> it's the wrong behavior. > > what's the definition of `wrong' here? Meaning that the patch Eric proposed is probably the better way to deal with ACKs. It wasn't meant to be taken too literally though, hence the "I think".
Re: [9fans] telnet vs. godaddy whois
>> On Thu, 17 Apr 2008 09:18:31 BST Charles Forsyth <[EMAIL PROTECTED]> wrote: >>> > having said that, i now suspect that sending one byte into a zero-window >>> > is >>> not the problem. >>> >>> because the one-byte probe can only be done if there is data to send, and i >>> already knew that a plain connection (dial only) to that port also failed: >> >> Not setting the PSH bit on a pure ACK (== no data is being >> sent) seems to fix this (see ip/tcp.c around line 2530). May >> be it tickles a bug on the receiver (0 byte read?). > > this does work for me. is there some subtile reason *to* set the psh bit > on a pure ack? in certain circumstances? > > good call. from rfc793, p 42: > > [...] If the the user signals a push function then the > data must be sent even if it is a small segment. > > minooka; 9diff ip/tcp.c > /n/sources/plan9//sys/src/9/ip/tcp.c:2529,2535 - ip/tcp.c:2529,2535 > } > } > > - if(sent+dsize == sndcnt) > + if(sent+dsize == sndcnt && dsize) > seg.flags |= PSH; > > /* keep track of balance of resent data */ > > - erik I noticed this some time ago when I was doing some work in the stack and thought it was very questionable. But I never got a chance to go back and do further research. Nevertheless I think it's the wrong behavior.
Re: [9fans] telnet vs. godaddy whois
> On Wed, 16 Apr 2008 12:04:23 PDT "ron minnich" <[EMAIL PROTECTED]> wrote: >> This is really an interesting discussion -- anybody think it could go >> on the wiki? I enjoyed it anyway :-) >> >> A good example of how correct behaviour (in this case Plan 9) can get >> you spanked. > > Er... "correct" seems a bit strong. Why is Plan9 sending one > byte of data when it knows the receiver's window is closed? > Lookup TCP persist timer and window probes.
