Re: [9fans] sendfd() on native Plan 9?
On Tue, Dec 23, 2008 at 11:14:16PM -0500, erik quanstrom wrote: > > All of the same comments apply to /srv (though srv^2 is trying to solve > > this). > > not true. import $server / /n/$server will give you access to srv on $server > as /n/$server/srv. Fair, but there's no reason to propose that an exportfs couldn't be the target of a sendfd(), or that the underlying mechanism for sendfd() couldn't be similarly exported (devcapsrv would work just fine, I think... maybe I should just write it and post code?). > what is "srv^2"? EricVH's /srv replacement. See http://graverobbers.blogspot.com/2008/12/srv-next-generation-service-registry.html > > 1) Sending files across namespaces so that I can spawn acme at rio startup > > and plumb to it without having to recreate mounts in its namespace. > > plumb "Local (bind|mount) args" will accomplish this. Assuming that the resource can be named in the plumber's namespace? This works out less well for things like ramfs's that were told where to mount (-m) and not to use /srv (-s). Or is there something really sneaky going on here that I don't know? > > 2) Sending parts of namespaces around locally without needing to run an > > exportfs in that namespace. (i.e. open() a directory && sendfd() that to > > another process who can mount() it.) Among other things, this allows the > > shell (and others) to easily offer the current working directory fd (rather > > than path) to rio for tab completion. > > you can't mount a random directory. OK, fair, it's more of a bind(). The operation does not yet exist, but should be quite easy to add. Perhaps it isn't worth it. > > 3) Some small thought about being able to implement srv^2 entirely in > > userland, and what the primitives would look like. sendfd() or the above > > outlined devcapsrv seems better than the current devsrv to me, but I confess > > I might be mistaken. > > what's the advantage of implementing srv entirely in userland? EricVH made some rumblings off-list about srv^2 being a userland thing, as it's a relatively complex proposal. Further, being able to write it entirely in userland also means that it is a virtualizable service, which /srv is not. > - erik pgpQo8YjYXbQG.pgp Description: PGP signature
Re: [9fans] sendfd() on native Plan 9?
> All of the same comments apply to /srv (though srv^2 is trying to solve > this). not true. import $server / /n/$server will give you access to srv on $server as /n/$server/srv. what is "srv^2"? > 1) Sending files across namespaces so that I can spawn acme at rio startup > and plumb to it without having to recreate mounts in its namespace. plumb "Local (bind|mount) args" will accomplish this. > 2) Sending parts of namespaces around locally without needing to run an > exportfs in that namespace. (i.e. open() a directory && sendfd() that to > another process who can mount() it.) Among other things, this allows the > shell (and others) to easily offer the current working directory fd (rather > than path) to rio for tab completion. you can't mount a random directory. > 3) Some small thought about being able to implement srv^2 entirely in > userland, and what the primitives would look like. sendfd() or the above > outlined devcapsrv seems better than the current devsrv to me, but I confess > I might be mistaken. what's the advantage of implementing srv entirely in userland? - erik
Re: [9fans] sendfd() on native Plan 9?
On Tue, Dec 23, 2008 at 08:39:27PM -0500, erik quanstrom wrote: > > /srv is not an ideal answer, though it is the one I feared would be given. > > /srv allows any process running as a given user to access the posted fd, and > > does not respect namespace or process group boundaries. I want a mechanism > > to pass a file descriptor to one target process so that I can pass an fd > > across namespaces without giving _all_ namespaces access to said fd. > > > > A /srv that 1) was not enumerable, 2) allowed only single opens, and 3) used > > secure identifiers (capabilities, similar to devcap) would suffice, as > > processes could post an fd to recieve an identifier, pass the identifiers to > > another process, and then turn the identifier into an fd. > > on unix, which is not a distributed system, passing fds around makes > a certain amount of sense. in plan 9, i would think that the ideal > answer would need to allow for the unrelated processes running > on seperate machine. i would also think that it would allow the > standard authentication mechanisms to work. fds really don't fit > either one of those criteria. All of the same comments apply to /srv (though srv^2 is trying to solve this). > but we're talking generalities. what's the specific application? 1) Sending files across namespaces so that I can spawn acme at rio startup and plumb to it without having to recreate mounts in its namespace. 2) Sending parts of namespaces around locally without needing to run an exportfs in that namespace. (i.e. open() a directory && sendfd() that to another process who can mount() it.) Among other things, this allows the shell (and others) to easily offer the current working directory fd (rather than path) to rio for tab completion. 3) Some small thought about being able to implement srv^2 entirely in userland, and what the primitives would look like. sendfd() or the above outlined devcapsrv seems better than the current devsrv to me, but I confess I might be mistaken. Thoughts? --nwf; pgp8x6KQGQavE.pgp Description: PGP signature
Re: [9fans] 9vx il has slight speed advantage
> i have a slightly unrelated question: what do you get if you use 'fcp' > instead of 'cp' for the same file over tcp and il? > > thanks great question. unfortunately a power problem has reconfigured my network for me and i can't generate comparable numbers just yet. - erik
Re: [9fans] sendfd() on native Plan 9?
> /srv is not an ideal answer, though it is the one I feared would be given. > /srv allows any process running as a given user to access the posted fd, and > does not respect namespace or process group boundaries. I want a mechanism > to pass a file descriptor to one target process so that I can pass an fd > across namespaces without giving _all_ namespaces access to said fd. > > A /srv that 1) was not enumerable, 2) allowed only single opens, and 3) used > secure identifiers (capabilities, similar to devcap) would suffice, as > processes could post an fd to recieve an identifier, pass the identifiers to > another process, and then turn the identifier into an fd. on unix, which is not a distributed system, passing fds around makes a certain amount of sense. in plan 9, i would think that the ideal answer would need to allow for the unrelated processes running on seperate machine. i would also think that it would allow the standard authentication mechanisms to work. fds really don't fit either one of those criteria. but we're talking generalities. what's the specific application? - erik
Re: [9fans] sendfd() on native Plan 9?
On Tue, Dec 23, 2008 at 11:52:51PM +0100, Rodolfo kix Garcia wrote: > Nathaniel, > > I am not 100% sure if my answer will solve your problem, but probably > you can do it using the 9P protocol. > > Look http://plan9.bell-labs.com/magic/man2html/5/0intro, 9P is the way > to comunicate the kernel with the proccess. Probably sendfd is not > needed in Plan 9. I think I understand 9P, but do not see why it removes the need for something like sendfd(). Can you explain further? --nwf; pgpCM2eFthmR7.pgp Description: PGP signature
Re: [9fans] sendfd() on native Plan 9?
On Wed, Dec 24, 2008 at 12:53:06AM +0100, Francisco J Ballesteros wrote: > You can post a fd at /srv for others to use /srv is not an ideal answer, though it is the one I feared would be given. /srv allows any process running as a given user to access the posted fd, and does not respect namespace or process group boundaries. I want a mechanism to pass a file descriptor to one target process so that I can pass an fd across namespaces without giving _all_ namespaces access to said fd. A /srv that 1) was not enumerable, 2) allowed only single opens, and 3) used secure identifiers (capabilities, similar to devcap) would suffice, as processes could post an fd to recieve an identifier, pass the identifiers to another process, and then turn the identifier into an fd. --nwf; pgpihmc2sjbvc.pgp Description: PGP signature
Re: [9fans] Cheap Native Plan9 ARM board?
On Tue, Dec 23, 2008 at 1:27 PM, Nick LaForge wrote: >> http://www.glomationinc.com/ > > i have adopted the 'technologic ts-7200': > > http://www.embeddedarm.com/products/board-detail.php?product=TS-7200 > > it runs netbsd, i have not started any plan9 work > ah. I should locate my half-assed plan 9 port and see if could help anyone. I'll start looking. ron
Re: [9fans] sendfd() on native Plan 9?
You can post a fd at /srv for others to use On 12/23/08, Rodolfo kix Garcia wrote: > Nathaniel, > > I am not 100% sure if my answer will solve your problem, but probably > you can do it using the 9P protocol. > > Look http://plan9.bell-labs.com/magic/man2html/5/0intro, 9P is the way > to comunicate the kernel with the proccess. Probably sendfd is not > needed in Plan 9. > > Saludos. > > Nathaniel W Filardo escribió: >> Is there any equivalent of sendfd() on native Plan 9? >> >> Thanks. >> --nwf; >> > > >
Re: [9fans] sendfd() on native Plan 9?
Nathaniel, I am not 100% sure if my answer will solve your problem, but probably you can do it using the 9P protocol. Look http://plan9.bell-labs.com/magic/man2html/5/0intro, 9P is the way to comunicate the kernel with the proccess. Probably sendfd is not needed in Plan 9. Saludos. Nathaniel W Filardo escribió: Is there any equivalent of sendfd() on native Plan 9? Thanks. --nwf;
Re: [9fans] 9vx il has slight speed advantage
i have a slightly unrelated question: what do you get if you use 'fcp' instead of 'cp' for the same file over tcp and il? thanks
Re: [9fans] Cheap Native Plan9 ARM board?
> http://www.glomationinc.com/ i have adopted the 'technologic ts-7200': http://www.embeddedarm.com/products/board-detail.php?product=TS-7200 it runs netbsd, i have not started any plan9 work nkl
Re: [9fans] rio startup fails in VMWare Fusion 2.0.0
> btw, what was your plan9.ini config? did it look like: > > vgasize=1280x800 > monitor=macbook (or xga?, sorry i am not sure about this) Before changing vgadb, I had success with: vgasize=1280x768x24 monitor=cinema > and, since we are in VM, does the native resolution really matter? my > thinking was, basically VM provides memory space and the graphics driver in > guest OS thinks this is its frame buffer. when a draw happens, the guest > OS's window gets updated. am i right or wrong? Sorry, I don't know the details. When you're not running fullscreen, there is obviously no real connection between the actual screen resolution and what the vm is simulating.
Re: [9fans] Acme scrolling tags (was Re: graphics scaling)
The P9P version has this too: acme -$ But that still doesn't address ease of Edit commands or tags full of build config strings and other crap. Yes, I've been relying more on tags than guide files of late. Paul On 23-Dec-08, at 10:54 AM, erik quanstrom wrote: (Really, it was easier to fix the editor than to get the rest of the team to move to a saner tree structure, aggravated by cross-platform/ cross-compile/cross-toolchain requirements that cause a 3 way cross product of both build and some sources. If only the world had been sold on Plan9 in 1993). wily being from and of the unix environment will substitute $fu for /some/long/string. - erik
Re: [9fans] Acme scrolling tags (was Re: graphics scaling)
> the obscenely deep tree our development happens in I sympathise, though ours is not _that_ bad. I use Plan9 as my desktop and mount parts of our server off a "work" dir in my home directory. This way I can work with short paths whilst remaining compatible with my colleagues. just my 2¢ -Steve
Re: [9fans] Acme scrolling tags (was Re: graphics scaling)
> (Really, it was easier to fix the editor than to get the rest of the > team to move to a saner tree structure, aggravated by cross-platform/ > cross-compile/cross-toolchain requirements that cause a 3 way cross > product of both build and some sources. If only the world had been > sold on Plan9 in 1993). wily being from and of the unix environment will substitute $fu for /some/long/string. - erik
Re: [9fans] Acme scrolling tags (was Re: graphics scaling)
That differs from my experience - I usually run 3 columns on a 30" monitor, with tags open to two lines for most of my active windows; the second line typically has an Edit command lying around because you can't effectively 2-1 chord Edits. The extra length is also useful for dealing with the obscenely deep tree our development happens in (Really, it was easier to fix the editor than to get the rest of the team to move to a saner tree structure, aggravated by cross-platform/ cross-compile/cross-toolchain requirements that cause a 3 way cross product of both build and some sources. If only the world had been sold on Plan9 in 1993). I use a mouse with a big click-able scroll wheel (yes, the cheap Dell ones) that lets me do my button 2 clicks well enough, but also let me scoll through my windows and tags - I find tag collapse and expansion really nice with the scroll wheel. Paul On 22-Dec-08, at 11:42 AM, erik quanstrom wrote: On Mon Dec 22 13:57:35 EST 2008, r...@swtch.com wrote: not ported. i'm glad that that hasn't been ported back. i find multi-line tags annoying 10 times for each time they are useful. is this an abstract assertion or have you actually tried them? russ i've used them for quite some time with p9p. i liked them at first, but it didn't wear as well as i thought it would for me. tags can be close to the length of the line and cause a second line to appear and disappear. i find that annoying and it happens more often than i need a long tag. esc esc then jolts things back the way they were. - erik
Re: [9fans] 9vx il has slight speed advantage
> On Mon, Dec 22, 2008 at 9:32 PM, erik quanstrom wrote: >> first from il >> ; time cat gs>/dev/null >> 0.00u 0.00s 9.70rcat gs >> >> next via tcp >> ; time cat /386/bin/gs>/dev/null >> 0.00u 0.00s 40.27r cat /386/bin/gs > > what about the host tcp? ftp is the easiest test i have. i hope this is close enough for a useful comparison. ftp> get gs /tmp/gs local: /tmp/gs remote: gs 200 Data port is tcp!192.168.0.4!53473 150 Opening data connection for /386/bin/gs (tcp!192.168.0.4!53473) 226 Transfer complete 13275174 bytes received in 1.24 secs (1e+04 Kbytes/sec) - erik
[9fans] sendfd() on native Plan 9?
Is there any equivalent of sendfd() on native Plan 9? Thanks. --nwf; pgpCxPRdGX3TE.pgp Description: PGP signature
Re: [9fans] 9vx il has slight speed advantage
On Mon, Dec 22, 2008 at 9:32 PM, erik quanstrom wrote: > first from il > ; time cat gs>/dev/null > 0.00u 0.00s 9.70rcat gs > > next via tcp > ; time cat /386/bin/gs>/dev/null > 0.00u 0.00s 40.27r cat /386/bin/gs what about the host tcp?
[9fans] Cheap Native Plan9 ARM board?
Hey guys, This was in my gmail ads this morning: http://www.glomationinc.com/ SBC ARM, 200MHz w/MMU, 32MB RAM, 128MB flash, Ethernet, Watchdog, RTC. Optional WiFi module over USB. $49 -- but that says `quantity' price. I don't know what it is at low quantity. I'll email. (Ok, I got the email. At low quantity, these devices are $85 each, which is super inexpensive for such a board) Wouldn't be too hard to port to, I don't think. Anybody interested? (Having worked on porting to ARM before, I'd be glad to work with anybody if they wanted to get feet wet with the kernel / jump into a fun project as well.) --dho
Re: [9fans] 9vx il has slight speed advantage
> 2008/12/23 erik quanstrom : > > first from il > > ; time cat gs>/dev/null > > 0.00u 0.00s 9.70rcat gs > > > > next via tcp > > ; time cat /386/bin/gs>/dev/null > > 0.00u 0.00s 40.27r cat /386/bin/gs > > I wonder if this is because of the timer in 9vx being less granular > and causing the TCP timer processes to fire late -- thus having to > deal with retransmits? il is using the same timer. - erik
Re: [9fans] 9vx il has slight speed advantage
> 2008/12/23 erik quanstrom : > > first from il > > ; time cat gs>/dev/null > > 0.00u 0.00s 9.70rcat gs > > > > next via tcp > > ; time cat /386/bin/gs>/dev/null > > 0.00u 0.00s 40.27r cat /386/bin/gs > > I wonder if this is because of the timer in 9vx being less granular > and causing the TCP timer processes to fire late -- thus having to > deal with retransmits? msec timing isn't good enough? i really doubt it. - erik
Re: [9fans] 9vx il has slight speed advantage
2008/12/23 erik quanstrom : > first from il > ; time cat gs>/dev/null > 0.00u 0.00s 9.70rcat gs > > next via tcp > ; time cat /386/bin/gs>/dev/null > 0.00u 0.00s 40.27r cat /386/bin/gs I wonder if this is because of the timer in 9vx being less granular and causing the TCP timer processes to fire late -- thus having to deal with retransmits? --dho > - erik > >
Re: [9fans] Plan9 on Mac with Parallels Desktop 4.0 for Mac
> But if you can tell parallels to use a different network > "card" it's worth a try. I don't think you can. It's RTL8029 (=ne2k) or nothing.
Re: [9fans] rio startup fails in VMWare Fusion 2.0.0
>tested so far, drawterm, 9vx are all so slow in updating inferno screen (i i tried running inferno in an 1152x900 x8r8g8b8 within 9vx. (the window is controlled by rio in 9vx but even then emu's draw operations go direct to the 9vx kernel via draw.) this is on a 1.2Ghz core duo on ubuntu 8.04. it "didn't seem too bad" (ie, not unusable) but it probably isn't as responsive as under plan 9 proper and if you're used to that you probably would notice the difference. i can't easily run them side by side for direct comparison. inferno applications will be drawing via Inferno's /dev/draw, with a screen implementation that ships updated rectangles to plan 9's using its 'y' and 'v' operations. the buffer size is determined by plan 9's iounit. inferno (on Plan 9 and thus 9vx) can be set to use plan 9's /dev/draw directly, so inferno applications will be bypassing emu's /dev/draw. it's a proof-of-concept scheme (ie, too many limitations at the moment for real use -- not because of draw but window management). i tried my script to run charon that way, under 9vx, and it was much, much worse than under wm through inferno's own draw, so that's not an immediate fix. it was really very bad. (by the way, the only significant reason for inferno's current indirection on plan 9 is to ensure the same draw code is used and tested in all implementations.)
Re: [9fans] Embedded MIPS board
On Dec 20, 3:46 pm, quans...@quanstro.net (erik quanstrom) wrote: > On Sat Dec 20 01:33:12 EST 2008, n...@cs.jhu.edu wrote: > > > Have people seenhttp://wiki.ubnt.com/wiki/index.php/RouterStation? Any > > idea on what porting the kernel to this guy would be like? > > keine ahnung. > > i didn't see any docs for it on the website. > i couldn't find any info on the chips i could > read in the picture. > > - erik What about this MIPS compatible one: http://asuseeehacks.blogspot.com/2008/10/worlds-first-open-source-netbook.html http://www.linuxdevices.com/news/NS2928309621.html http://www.lemote.com/english/yeeloong.html http://www.gdium.com/en/product/liberty1000 http://en.wikipedia.org/wiki/Loongson antonio
