Re: [9fans] 9vx on x86-64
2008/12/11 Russ Cox r...@swtch.com: On Thu, Dec 11, 2008 at 4:04 AM, simplicity plan9assemb...@gmail.com wrote: On Dec 9, 6:45 pm, r...@swtch.com (Russ Cox) wrote: 9vx now builds and runs on Ubuntu Linux x86-64, and hopefully other Linuxes as well. It also runs gs and ape/psh correctly. I haven't built new binaries nor a new distribution. Soon; perhaps tomorrow. Russ please give it to me :) you can get it yourself as long as you want to compile it: http://hg.pdos.csail.mit.edu/hg/vx32 russ I've got a patch at this point that gets it to build on FreeBSD/amd64, but it dies in the trap handler (surprise, surprise). There are a couple other things I've added / plan to add shortly. Russ, should I just keep sending patches your way? --dho
Re: [9fans] Wireless cards
2008/12/15 theotherji...@gmail.com: Hello, I was wondering if Plan 9 supports wireless Ethernet in its current state. If it does (and I just can't find it), could you please give me a link to follow. If it does not, I guess I will just begin to analyze my current wireless driver (for Linux) madwifi. Please see the wiki: http://www.plan9.bell-labs.com/wiki/plan9/Supported_PC_hardware/index.html Thank you for reading my first post, Jimmy --dho
Re: [9fans] devtrace release time
2008/12/17 ron minnich rminn...@gmail.com: On Wed, Dec 17, 2008 at 12:08 PM, Uriel urie...@gmail.com wrote: Didn't know the amd64 kernel doesn't live in /sys/src/9/pc/. OK, I am only responding to this because of the incorrect impressions being left by these kinds of comments. The backport John did is to the standard kernel that you all can get on your machine. It should in fact even work on 9vx. You are welcome to use it. In fact, one could actually look at what John released *before* posting to this list and making oneself look silly. It's an idea. It doesn't (yet) work on 9vx. I'm working on that right now, though. More on that in a later message. --dho great unwashed masses? I am reminded of a liberation sign somebody spotted in some foreign land once: The Masses are Revolting! :-) ron
[9fans] 9vx Patches
Hey guys, Back in my ``let's have fun with Plan 9'' yearly phase. Here I come back and I see some really cool work. 9vx definitely is the coolest thing I've seen so far, and devtrace looks pretty nifty too. What's really cool to me about them is that they're available and there is open work to be done with them. So I've started hacking away. My 9vx has a couple changes that I found useful / thought would be fun to implement / thought others might find useful. A brief synopsis: * Memory bounds -- gives 9vx an upper bound on resident memory usage as it limits the size of the pagefile. Set by running 9vx with -m [MB] * CPU bounds -- only works on FreeBSD so far. I've got a Linux port of that management code, but it doesn't seem to actually do the right thing (and it hasn't been a priority to fix since I rarely run Linux). I do plan on fixing it, but if someone else wants to fix it first, that'd be fine by me, too. Darwin support looks unlikely because, although the libkvm stuff is there and likely would work after just changing some of the member names of where things look, it has neither a clone(2) or rfork(2) implementation. If anybody has an idea about how to spawn and disassociate a child process in Darwin so it doesn't receive its parents' signals, let me know. Set by running 9vx with -l [% CPU]. * Set window width/height on the console. Set with -w [width] and -h [height], respectively. * Lock tracing. I needed this when debugging some of the netstack stuff because I screwed up a qunlock which deadlocked the system. Set by toggling -L. Things in the works: * Native Plan 9 netstack. It's ported, it compiles, but my virtual ethernet device doesn't seem to be transmitting anything (though I haven't done any extensive tests). See also: http://testbed.dh0.us/~dho/fuxyes.png * Porting devtrace. Needs some changes to compile with gas; the #pragmas are useless, but I think should work after a little more tweaking. * FreeBSD/amd64 support. I don't think it works yet, but it compiles. I don't rightly understand what all the LDT modification does on Linux x86_64 in relation to what I'm actually doing with %gs (hints from people with knowledge welcome). Other stuff * Automatic provisioning via a web browser. Yeah, Plan 9 in the web browser (if you have Java, I guess -- otherwise it's just VNC). http://testbed.dh0.us/ -- this code isn't version controlled, but I could probably put it in hg with little effort. The code for the rest of the stuff is at http://testbed.dh0.us:8000/ --dho
Re: [9fans] 9vx Patches
2008/12/17 Roman Shaposhnik r...@sun.com: On Dec 17, 2008, at 4:10 PM, Devon H. O'Dell wrote: * Automatic provisioning via a web browser. Yeah, Plan 9 in the web browser (if you have Java, I guess -- otherwise it's just VNC). http://testbed.dh0.us/ -- this code isn't version controlled, but I could probably put it in hg with little effort. Really nice bunch of things! I'm looking forward to seeing the implementations. As for the above service -- is it currently off-line? I can log-in and create an instance, but when I try to connect to it here's what I get: Thanks! The 9vx that is installed by this though is the one from Russ's tip... mine's still not perfect and currently doesn't do any networking. snazvx: dashboard control id namestate activateview 10 rvs-testrunning stopview (or vncviewer testbed.dh0.us:5810) The vncviewer text is wrong; it's just vncviewer testbed.dh0.us:10 -- I haven't fixed this yet :( vncviewer: ConnectToTcpAddr: connect: Connection refused Unable to connect to VNC server Thanks, Roman. --dho P.S. Has anybody experimented with running 9vx on Amazon's EC2 yet? I would if it was free and I didn't have a server :\ --dho
[9fans] Help with device and clone?
I really am getting to the deep guts of dev.c and chan.c here in debugging why when ip/ipconfig tries to open /net/ether0/clone, it's getting Enotfound. From my latest commit: Fix some stuff with the ether controller attaching. It attaches now, but for some reason clone screws up. I have no idea why; domount is failing to work in 9vx/a/chan.c when we are doing the walk over the path which in turn causes us to try to find the file in rootgen instead of going to the other side of the mount and looking for it in /ether0/clone. Help? It's entirely possible (and almost entirely clear) that I'm missing something obvious, but I'm not sure what it is. The virtual device is at http://testbed.dh0.us:8000/file/dfc493421329/src/9vx/etherve.c for the current revision -- feel free to browse around or clone my repo. I'm going to sleep now, but any help would be appreciated. --dho
Re: [9fans] Help with device and clone?
The link routines happen very early, before any user code has run. /lib/namespace is processed by user code. So when the links are running, I think it is simply that there is nothing bound to /net. Russ Thank you... I think I see the issue now. I'm also enjoying: 245 /* set up the network so we can talk to the venti server */ 246 /* this is such a crock. */ Yes, yes it is... --dho
Re: [9fans] Help with device and clone?
2008/12/18 erik quanstrom quans...@quanstro.net: Thank you... I think I see the issue now. I'm also enjoying: 245 /* set up the network so we can talk to the venti server */ 246 /* this is such a crock. */ Yes, yes it is... --dho we would all love it if you allowed venti to accept a fd instead of a tcp connection. Maybe I will try to after I understand this a bit better, because it's still not working, and I'm introduced with a couple of issues that I'm still not coming around with solutions for -- that set-up is a really huge hack. I guess I knew it was like that. It seems to be a chicken-and-egg type problem, which I don't think it is. I can't really kbind(#I, /net, MAFTER); at the time that I'm calling ethermediumbind -- it's too early for that. At the same time, I can't really move the links and makekprocdev(ipdevtab); to the area in init0() where kbind()s happen. Maybe I'm missing something totally obvious here, but there must be some way for me to call ethermediumbind() and change its namespace view -- but so far nothing's happening when I add: kbind(#Zplan9/, /, MAFTER); +kbind(#I, /net, MAFTER); +kbind(#l0, /net, MAFTER); kbind(#p, /proc, MREPL); in init0. --dho
Re: [9fans] Help with device and clone?
Meh, I keep forgetting to hit reply-all or something. 2008/12/19 erik quanstrom quans...@quanstro.net: That's where I was looking initially -- it looks like that's all only done when you're connecting to a venti, and it seems like it definitely happens after the links run anyway. Links happen after initseg(); that stuff happens in bootinit() in Plan 9 proper -- so that's where I did it in 9vx. I'm tempted to just use '#l' in ip/chandial.c right now until I have a more concrete idea about where binds *should* happen. There are still issues with etherve that I need to hammer out, I think. --dho sorry. i haven't really been following along. i am confused by the fact you're having troubles. if you're doing things in the same order as the native kernel, i don't see how you could be getting different results. unless there is some hack in 9vx that causes things to happen differently. There seem to be some differences in how things happen at start-up time, but they don't seem so severe. That's why I'm asking here :) (you're virtual ether0 is working now, right?) It works if I force chandial to look for it in '#l', and by works, I mean I haven't been able to test it on a live network yet :( --dho - erik
Re: [9fans] Changelogs Patches?
2008/12/22 Venkatesh Srinivas m...@acm.jhu.edu: Hi, The contrib index mentions that daily changelogs for Plan 9 are in sources/extra/changes, but those haven't been updated since early 2007. Is there any preferred way to get changelogs / diffs these days? I used to maintain the changelogs, but ended up generating ENOTIME, pretty much just as everyone else who has worked on that. It's something I think I might pick up again; either Russ or Uriel emailed me a set of scripts to maintain it. Perhaps I'll start doing it again; it's mostly just a question of getting the scripts set up and doing it. --dho Also, in sources/patch, there are patches neither in applied/ or sorry/. Are these patches in queue? Applied? Not applied? Thanks, -- vs
Re: [9fans] 9vx wrong up? or wrong pgrp?
2008/12/22 erik quanstrom quans...@quanstro.net: sorry to reply to myself, but the up in the kernel belongs to an *io*, not the calling process. That's weird, the up in the kernel that I was seeing belonged to *init*. If you go further down into: walk error 2: does not exist You will see the error comes from domount() returning false in rootdevgen, I believe. - erik --dho
[9fans] Native TCP/IP stack in 9vx working
Hey everyone, Over the past few days, Erik Quanstrom has been helping debug issues with the native IP stack in 9vx. He figured out some crazy issues with gcc wanting to return negative values for signed modulo comparisons -- this combined with a stupid oversight has got IP working. Erik says he's moving IL in tomorrow -- at this point, that shouldn't be a huge deal. Linux seems to have better performance than FreeBSD/Darwin -- this is because Linux lets you read TCP/UDP over a raw socket. BSD platforms don't let you do that -- you have to use BPF for this -- and libpcap makes that a bit easier -- so I think there's a bit more overhead involved with that. Also, there's still a fair amount of probably useless debugging stuff that we could conditionalize at compile-time, but I'll leave that in for a while before that happens. Please test it out! http://testbed.dh0.us:8000/ Big thanks to quanstro for his huge help in debugging. --dho
[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 as a cpu server?
2009/2/1 Mathieu lejat...@gmail.com: As I naively see it, the two main problems are: 1) to have 9vx running a cpu server kernel instead of a stand alone terminal one (I don't even know if that's the case actually). i think there would be a little work in getting this going. Ok, so it's possible then. :) I'll see if I can understand the 9vx code and have a go at that. 2) to have the host forwarding whatever packets should go to 9vx. is this enough? http://9fans.net/archive/2008/12/501 http://9fans.net/archive/2008/12/505 Hmm I'm not sure, do these modifications imply that the Linux/FreeBSD host can see 9vx as another host? Hence making it possible to NAT the relevant traffic to it? If yes, then that's indeed what I'm after, thx. You add an IP address to your system; with the changes, 9vx creates a virtual network device. You assign the IP address to the 9vx virtual network interface and it does the right thing. It isn't NAT, it's passive traffic listening / injecting. I still have some work to do to get the tap driver running, but it's been on the back burner. --dho Cheers, Mathieu
Re: [9fans] Flash Video
2009/2/2 Akshat Kumar aku...@mail.nanosouffle.net: 2009/2/2 Skip Tavakkolian 9...@9netics.com: it might require a c-section. might want to start with VLC or ffmpeg. My aim was just to get 9fans talking about it. Hence, the pushing. But yes, what information can you provide about either of those, with regards to porting or creating natively? The Flash file format is an open standard (http://www.adobe.com/devnet/swf/). To be useful for encoded video, you'd need a VP6 codec (which seems lolno) and x264. It would probably be possible to do at least the x264 stuff via ffmpeg, which is probably not too difficult to port -- it's pretty simple code and the codecs are easily portable. To be useful for anything else, you'd also need a bytecode interpreter that understood the compiled actionscript -- it's just a bytecode-compiled ECMAScript, and I believe its details are also found in that PDF. The rest is being able to display JPG/PNG raster images and antialiased TTF and vectors. (Flash allows you to embed fonts into the generated SWF output as well). --dho ak
Re: [9fans] Flash Video
2009/2/3 Skip Tavakkolian 9...@9netics.com: the original question was about flash video. many here seem to have interesting ideas, but obviously not motivated enough to want to plan/research/read/understand. two clues: mpeg4 and rtp I think you mean RTMP. There are a couple of open RTMP transporters, the only functional ones I've seen are in ruby and Java. --dho By the way, Gnash seems to be quite useful.
Re: [9fans] Web interface to '/n/sources/contrib' gone??
All parody aside, Bruce, the service did exist at one point, and it existed because it was useful to enough people for the labs to make it and set it up. It's been available for several years. Hiccups aside, it's a bummer that it's down for so long. At this point, I'd think it would be obvious that there are people other than the 5 of us who actually have a Plan 9 machine to drawterm into or an easily-accessible 9vx instance. Even despite the fact that I *do* have access to Plan 9 machines and that I *do* have access to 9vx instances, I find myself looking at the web-exported source during times it would be infeasible for me to access them (while I'm at work, for instance). This is the same thread that comes through 9fans monthly -- - ``What happened to X?'' = ``Screw X'' - ``But I actually use X'' = ``Who cares'' = ``X sucks and so do you'' = ``Go blow goats, etc.'' I can appreciate the humor, but not at the expense of dismissing the problem. If the labs don't want to keep the thing running, great, someone else can sync with sources and provide that interface. So, let's change the question: ``Labs guys, is that thing dead, and should we set another one up -- or are we back in another hiccup period?'' ``Mockery is easy. Helping people is hard.'' It amuses me that, having come up with such a degrading rant about wanting to access sources via HTTP, you're sending email on your proverbial Nintendo Lego blocks. --dho
Re: [9fans] Web interface to '/n/sources/contrib' gone??
2009/2/10 Bruce Ellis bruce.el...@gmail.com: I just hate all the non-technical whining on here. Agreed Can someone look into the web interface? would have worked. Agreed brucee -dho
Re: [9fans] 9vx and native networking
2009/2/11 erik quanstrom quans...@quanstro.net: On Wed Feb 11 07:27:47 EST 2009, ano...@gmail.com wrote: Devon got this working for him about a month and a half ago; see this message: http://9fans.net/archive/2008/12/501 I've still not made it work for me (on OS X), but i think the issues are actually in changes outside the ethernet stuff. I haven't had much time to dig in. it's been working well for me. i've been using etherrs (raw socket) on linux. the pcap version didn't work very well for me. probablly due to some linux misconfiguration. also, if you're looking to ping, make sure that the filter compiled into etherve.c doesn't drop non-ip packets. arp is not ip. I fixed that issue some time ago; it turned out that the performance issue was something that is built into pcap to buffer packets for a certain time period. So there was always an additional 500ms latency on it because it was waiting that long before it returned its packet buffer up to the OS. I believe I also have the code in hg doing the right thing with the filter, as the pcap version did end up working for me. --dho unfortunately, what you can't do is boot from a plan 9 fs. and since 9vx requires many more cycles and much more memory than drawterm, i've fallen back to that. a faster linux machine might have lead to a different decision. - erik
Re: [9fans] Venti by another name
On this note, Marco Peereboom has been working on epitome: http://www.peereboom.us/epitome --dho
Re: [9fans] threads vs forks
2009/3/3 J.R. Mauro jrm8...@gmail.com: Concurrency seems to be one of those things that's too hard for everyone, and I don't buy it. There's no reason it needs to be as hard as it is. That's a fact. If you have access to The ACM Queue, check out p16-cantrill-concurrency.pdf (Cantrill and Bonwich on concurrency). And nevermind the fact that it's not really usable for every (or even most) jobs out there. But Intel is pushing it, so that's where we have to go, I suppose. That's simply not true. In my world (server software and networking), most tasks can be improved by utilizing concurrent programming paradigms. Even in user interfaces, these are useful. For mathematics, there's simply no question that making use of concurrent algorithms is a win. In fact, I can't think of a single case in which doing two lines of work at once isn't better than doing one at a time, assuming that accuracy is maintained in the result. --dho
Re: [9fans] GSoC 2009
2009/3/4 Anthony Sorace ano...@gmail.com: So, the web site's up, program is announced, and so on. Was anyone planning on doing a Plan 9 application? I'm willing to help, if anyone was planning on it, or lead, if not. In the later case, I'd appreciate help (any of advice, materials, or labor) from people who were involved in our last two applications. Anthony Anthony, Let's catch up off-list to discuss this. There's a bunch of stuff to do. --dho
Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook
2009/3/20 ron minnich rminn...@gmail.com: On Fri, Mar 20, 2009 at 4:52 PM, James Tomaschke ja...@orcasystems.com wrote: I would suggest the compiler as well, students are probably more familiar with compiler concepts and it will probably be easier to mentor. In the future, the porting work can be distributed over the community anyways. Sorry, I was not clear: I only meant a mips-64 compiler port. I think so. Who wants to mentor? I'd be up for getting one of these puppies if anybody wants to do it (though they are rather expensive considering no US distributor... harrumph) and mentoring to some degree, but I'm more likely to want to help out with (and probably a better contact for) 9vx work than that. --dho
Re: [9fans] Plan 9 on Routers?
2009/3/24 Rahul Murmuria rahul.is.a...@gmail.com: I was poking around for what it would take to get there. I found this[1]. I am basically looking to have a way to do routing using Plan 9. You can already do that on any standard Linux using Quagga[2] based on GNU Zebra. Maybe there is a filesystem that exposes the kernel routing table to user space for certain routing algorithm scripts to hack upon? My objective is to be able to implement a new routing protocol on a router created using a standard computer with multiple NIC cards, maybe on a model P2P type network? I also would love to see what having /net on a router would enable us to do. Has anyone any experience with using Plan 9 on routers? Are you a student? This kind of stuff has interested me quite a bit in Plan 9 (though more from a packet classification standpoint -- read: firewalling), and it seems like a nifty project for GSoC. As far as I'm aware, there is nothing similar to the OSPF/BGP/RIP support directly in Plan 9. I am pretty sure Charles has written a RIP daemon that is in sources somewhere. --Devon -- Rahul Murmuria [1] http://searchenterpriselinux.techtarget.com/tip/1,289483,sid39_gci1102834,00.html [2] http://www.quagga.net/docs/quagga.html#SEC3
Re: [9fans] Plan 9 on Routers?
2009/3/24 Rahul Murmuria rahul.is.a...@gmail.com: @ Devon: About Packet Classification. I read that iptables is not needed on Plan 9 because its mount /net over the network concept achieved anonymity or transparency -- something along those lines. There are no logs about who is sending what, and that is a good thing. This is a flawed argument. If using Plan 9 as an edge router instead of a bridge, it's imperative to have some sort of filtering. This doesn't just apply to NAT situations (and even then, mounting /net isn't really the same thing as NAT). There is ipmux, but as Eric says, it's not fleshed out enough to implement NAT. Eric also says: ``as long as you restrict your network to plan 9 machines, it is possible to import /net from a gateway machine and avoid sticky things like packet filtering.'' This is a good idea in theory, but in practice most machines are not Plan 9 and there's almost always a need for a heterogeneous environment. Some would solve this by porting the ability to `import /net' to other operating systems. My feeling has always been that some sort of packet filtration system should exist to make Plan 9 useful in routing in such heterogeneous networks. It's easier to do and would facilitate wider adoption (whether that's a good thing or not is always up for debate). I am not sure where exactly the packet classification idea fits in. I read in the /proc documents that /proc/net provides useful information about the network stack. There is this ip_conntrack which is used to list / track network connections. I wonder what we would need to get packet information and perform filtering. Is it desirable to get that filtering to work if it already does not exist? I believe I have a rudimentary and probably non-working (at this point) packet filter in /n/sources/contrib/dho somewhere (it was written at least 4 years ago). I think it's called ``nfil.'' I believe it is desirable. Others disagree. Its usefulness is related directly to its application, and without it, there's no way to test Plan 9 in an environment in which it would be useful. You said earlier ``I qualify for GSoC but I was planning not to apply, as from where I see it, that brings in restrictions to the independence of thought. I am open to applying though, if this is a good enough (and small enough) idea for SoC.'' -- I'm not sure why you think that the idea of the SoC project restricts independence of thought -- I've certainly never seen it as such. While creating an entire routing suite (such as Zebra/Quagga) is probably outside of the scope of a 3 month project, I think a diligent student could probably do something useful with OSPF or BGP. It's entirely possible that a 3 month project could consist of analyzing Plan 9's ability to function in this environment and making changes to facilitate the implementation of routing protocols. Or creating a packet filter. In either case, I'd personally be excited to see this suggested as a SoC project if it was well thought out. I've wanted to work with somebody on Plan 9 as a routing device in networks for some time, at least in the field of packet classification. Thank you all for replying so far! No problem :) --dho -- Rahul Murmuria
Re: [9fans] Plan 9 on Routers?
2009/3/25 erik quanstrom quans...@quanstro.net: I believe I have a rudimentary and probably non-working (at this point) packet filter in /n/sources/contrib/dho somewhere (it was written at least 4 years ago). I think it's called ``nfil.'' I believe it is desirable. Others disagree. Its usefulness is related directly to its application, and without it, there's no way to test Plan 9 in an environment in which it would be useful. why not extend the packet filtering capabilities of the existing #I? That's what it did, if I recall correctly. --dho - erik
Re: [9fans] request for more GSoC project suggestions
2009/3/25 Charles Forsyth fors...@terzarima.net: [snip] I don't know where the best place to suggest or discuss them would be, but I thought this list would reach nearly everyone interested. I've sort of volunteered myself to webmaster the gsoc.cat-v.org page for this year's SoC, so if you have any ideas you'd like to get on there, just mail them to me, or to the plan9-gsoc mailing list and I'll get them plopped up there. I agree with your points, and I think some decent application ideas are in order. --dho
Re: [9fans] Plan 9 on Routers?
2009/3/25 Bakul Shah bakul+pl...@bitblocks.com:
On Wed, 25 Mar 2009 09:00:58 EDT Devon H. O'Dell devon.od...@gmail.com
wrote:
While creating an
entire routing suite (such as Zebra/Quagga) is probably outside of the
scope of a 3 month project, I think a diligent student could probably
do something useful with OSPF or BGP. It's entirely possible that a 3
month project could consist of analyzing Plan 9's ability to function
in this environment and making changes to facilitate the
implementation of routing protocols. Or creating a packet filter.
Thinking a bit more about it, extending /net/iproute to allow
routing metrics may be what is needed for porting/building
something like openospfd or openbgpd. Basically
/net/{iproute,ipifc} etc need to do more or less what a
routing socket does under *BSD (man 4 route). Of course,
there may be other things missing in the p9 IP stack that may
get in the way but now I think porting something like
openospfd in a summer is doable.
Yeah, that's what I meant to imply :) Thanks for clarifying that :)
--dho
Re: [9fans] request for more GSoC project suggestions
2009/3/25 Paul Lalonde plalo...@telus.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to see a 3D graphics protocol. Then I could run the host on some linux or window or mac box to do the display, and run the graphics app in Plan9, or inferno, or ... And (heresy aside) I've love a way to compile C++ programs for plan9. That would give me a reason to get Plan9 up on this scary multi-core part I'm working on. Without C++ support, I can't run the principle application I need :-( Gogo reimplementation of cfront. Paul On Mar 25, 2009, at 8:16 AM, Charles Forsyth wrote: There are GSoC project suggestions at http://gsoc.cat-v.org/ideas/ but I think more are needed, and that it would be especially good to have a further set of useful but simpler and smaller projects. Projects need to be non-trivial for GSoC, but shouldn't be hard enough that many of us would shun them (or indeed, have shunned them). Based on my experience several years ago, I'd also look for projects that are modular, so that the set of deliverables can be extended or reduced depending how things go. That worked well for the projects I was involved with. The problem with ports of the system or device driver writing, in my experience, is that satisfying though they are, and as necessary as they might be, they are typically quite hard to supervise, and will usually be fairly difficult for relative novices. There is quite a bit to learn for most students just to get started and be productive in the programming environment, although 9vx does make that much easier. Application-level projects are typically easier to supervise because they don't need specialised equipment, and many more people on this list and elsewhere can help with plausible advice, and also help debug when students are stuck. (Advice will sometimes be contradictory, but that's not a bad lesson to learn, too.) It's quite hard to help when special hardware or kernel-level debugging is involved. Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at user-level that is done at kernel-level in other systems, that shouldn't narrow the scope much. I wrote application-level not just user-level earlier because I thought it would be good to have some interesting applications of the system. Of course, I don't mean to preclude system-level things when students are especially keen on that (as indeed I was during my school and university years). I don't know where the best place to suggest or discuss them would be, but I thought this list would reach nearly everyone interested. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFJyoybpJeHo/Fbu1wRAoi3AKCTQLsrxzBt7m94P3LsOR+o85KungCfT6Ms o+vaJtOAjx1IxDqCtWskyQY= =FvNd -END PGP SIGNATURE-
Re: [9fans] looking for a project
If you're interested in participating in the GSoC program, or for ideas on open projects, take a look at http://gsoc.cat-v.org/ideas/ --dho
Re: [9fans] request for more GSoC project suggestions
Another student I spoke to on IRC spoke of the possibility of bootstrapping LLVM for Plan 9 on Linux and getting it to run natively. That would give us a whole bunch of different compilers. --dho
Re: [9fans] GSOC: Drawterm for the iPhone
2009/3/25 Federico G. Benavento benave...@gmail.com: do we need drawterm for the iphone? is anyone going to use it? I mean, it's a tiny screen, typing on handhelds sucks, plus is not that there is killer app Plan 9 has that you _must_ run. am I forgetting something obvious? Tiny screen, but reasonable resolution. Should find out who put it on the ideas page for GSoC; it wasn't me (so clearly somebody is interested). Besides, look at the DS port. Smaller screens, lower resolution (even combined, I think). Whether it's novelty or not isn't for me to say, but I can see how it would be useful. --dho
Re: [9fans] request for more GSoC project suggestions
2009/3/25 Federico G. Benavento benave...@gmail.com: [snip] As for applications for Plan 9, the ones we need (read to cope with the rest of the world) are too big for a soc project, so even if I don't like gcc, a port would help on this matter. Yes and no. As long as there are reasonable expectations for the projects, there is no reason an application or application suite cannot be duplicated or ported. GSoC isn't entirely about completing a project: the scope of a project may just be laying groundwork or a foundation for a later project which involves the porting. I think a lot of your sentiment about the GSoC program is a bit short sighted (based on emails in 2 threads now). right now, one can get by running old linux binaries and linuxemu+ equis, so improving linuxemu is also a project I'm interested. just my opinion Linux emulation can always use work everywhere, especially since those assholes keep changing it every chance they get. More syscalls for more glibc versions = good. FreeBSD's linux compat works great these days (so it may not be a half bad place to start looking for improvements, though, admittedly, I haven't used linuxemu on Plan 9) --dho
Re: [9fans] GSOC: Drawterm for the iPhone
2009/3/25 andrey mirtchovski mirtchov...@gmail.com: there are a couple of other problems that I see with dt on the iPhone: - platform: google may be much more interested in seeing apps for the G-phone than they are for the rival (but then, a g-phone version may be much easier to do, and not worth a gsoc) - barrier to entry: the student should have an iPhone (the simulator is only somewhat sufficient). - barrier to entry: the iPhone development kit costs $99 (that's not the SDK, which is free) and puts you through a few too many hoops just to order a development token for your phone, then much more stuff to put it into the AppStore. it's not pretty. i don't want to turn anyone off from the idea: if anyone thinks it's worth it go for it. The only thing barring the student who wrote this proposal from completing it is the iPhone development kit (which I will fund if he's accepted and I have to, $99 really isn't that much) and a bunch of people on this list saying it's a bad idea. I think the 3.0 SDK fixes some of the problems that have been mentioned in this thread, and I think it does raise interesting challenges. He already has an iPhone, ObjC experience, and XCode experience. Also: ok, you can't compare porting inferno to the ds with drawterm for the iphone drawterm is an app to get to a Plan 9 server, inferno is a self contained operating system where you can get the advantage of writing your own apps for it. Except that drawterm ends up being a mini-Plan 9 kernel like everything else out there. The concepts aren't so different. Either way, SSH clients exist for the iPhone. Are those useless because it's hard to type commands on native keyboards and the text is tiny. --dho
Re: [9fans] request for more GSoC project suggestions
I'd like to note again that I was kidding about cfront _ 2009/3/25 Paul Lalonde plalo...@telus.net: A cfront-ish approach to templates leads to hellish duplication of template-generated code in each module, and thence to even worse code bloat. Of course, my understanding of what's possible in a cfront translation is perhaps (probably) naive. Paul On 25-Mar-09, at 2:12 PM, Charles Forsyth wrote: A modern cfront is nearly impossible. Templates make it hella-hard. really? how is that?
Re: [9fans] request for more GSoC project suggestions
2009/3/25 erik quanstrom quans...@coraid.com: On Wed Mar 25 19:22:23 EDT 2009, devon.od...@gmail.com wrote: Another student I spoke to on IRC spoke of the possibility of bootstrapping LLVM for Plan 9 on Linux and getting it to run natively. That would give us a whole bunch of different compilers. --dho at the risk of being called stupid twice in one day, i have to say i don't see what the payoff would be. doing something with gcc helps with gcc-specific code. what does llvm give us? OMG STOOPID. Just kidding, of course. I think the gist behind LLVM is that compilers can target it as a machine type, and it is able to create native binaries for its own supported machine type for anything that can run on it. So any compiler that can target LLVM would be able to target Plan 9. (Which is several of them) - erik --dho
Re: [9fans] request for more GSoC project suggestions
2009/3/26 lu...@proxima.alt.za: so if you have any ideas you'd like to get on there, just mail them to me, or to the plan9-gsoc mailing list and I'll get them plopped up there. I'm actively working on GCC from two directions: a port of the Plan 9 libraries to a cross-compilation environment under NetBSD (I have Ubuntu handy as well, so that becomes an option) and implementing ELF support in the Plan 9 kernel. The latter requires familiarity with Linuxemu which in turns provides two useful extensions besides its own value: ELF and MMAP. MMAP is so ubiquitous, someone ought to be looking into it, but it won't be me until ELF is sorted out. ^ I have no idea whether any of these are potential GSoC projects, but anyone who wants to contribute is welcome in whatever way they like. Alright, sounds good. Are you signed up as a mentor? (I'm not an admin, so I don't know). I'll add this to the ideas page; if you're interested and able to mentor, this would be a great project, I think. --dho ++L
Re: [9fans] Plan 9 on Routers?
2009/3/26 lu...@proxima.alt.za: I've wanted to work with somebody on Plan 9 as a routing device in networks for some time, at least in the field of packet classification. I'll be happy to help, too, if so desired, I have been playing with IPFilters in a pretty serious way for many years (and ipfw before that) and may well be able to contribute my experiences in this field. Sweet. Perhaps I'll re-implement the hookable filters into 9vx. The interface is a more difficult problem than a proof-of-concept filter (which I've implemented a few times). Maybe we should talk about ideas for rule lookups and the like off-list? I'll put it up as an idea again this year as well, and see if anybody bites. --dho ++L
Re: [9fans] GSOC: Drawterm for the iPhone
2009/3/26 Eric Van Hensbergen eri...@gmail.com: On Thu, Mar 26, 2009 at 7:30 AM, Federico G. Benavento benave...@gmail.com wrote: I mean, drawterm for the iphone! why not for symbian? I'd have no problems with those suggestions either, as far as multitouch goes there are probably even further platforms -- even just support of 2 simultaneous mice. But the student seems keen on iphone, and if there is a mentor similarly interested then I don't see a problem. +1 -eric
Re: [9fans] GSOC: Drawterm for the iPhone
2009/3/26 erik quanstrom quans...@quanstro.net: so please stop saying that 9vx or inferno make drawterm obsolete until that's actually true. Additionally, both 9vx and inferno do actually execute code, which would facilitate a breach of the SDK license. - erik --me
Re: [9fans] request for more GSoC project suggestions
2009/3/26 Juan M. Mendez vej...@gmail.com: Maybe porting parrot (http://www.parrot.org ) to Plan9 would be an interesting Gsoc project My co-worker is the backup org admin for Parrot (but is responsible for the Perl 6 and Parrot programs). If there's real interest here, submit a proposal for a port to Plan 9 to both projects, and we'll work something out to co-mentor. If both projects get an application, the chances of that actually happening do increase. --dho Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. This is the list of languages at different status of support: http://www.parrot.org/languages -- http://vejeta.com/portal Fidonet: 2:345/432.2
Re: [9fans] GSOC: Gitfs
2009/3/26 Roman Shaposhnik r...@sun.com: Somehow I didn't see the original email from Manzur (was it ever posted to the list?) But given my personal interests, I'd be delighted to help along with the gitfs. Yeah, it was. Since I've ignored most of the GSOC traffic so far, could someone, please point me to the right URLs so that I can see what's required of mentors and whether I'd be a good match for that. The GSoC traffic is misdirected. The GSoC emails *SHOULD* be going to the plan9-gsoc list, which is hosted by Google. As far as becoming a mentor, create a google account, and go to http://socghop.appspot.com/org/apply_mentor/google/gsoc2009 Anthony Sorace is the administrator for the project this year and he will have to approve your mentor application. Thanks, Roman. Hope that helps! --dho P.S. besides, there's always a benefit of communicating in Russian or getting together for a few beers in SPB ;-)
Re: [9fans] GSOC: Drawterm for the iPhone
2009/3/26 Pietro Gagliardi pietr...@mac.com: On Mar 26, 2009, at 3:35 PM, Eric Van Hensbergen wrote: I'm merely trying to debunk roadblocks which others seem to want to through in his way. I don't want to throw a roadblock in this student's way. (In fact, drawterm on iPhone benefits me too, though that benefit would come in or after June :-| ) I just tried to point out a few hurdles. That's what design and development is for: jumping hurdles. I think Eric's sentiment is more towards that those `hurdles' aren't actually hurdles at all and are misinterpretations that caused about 20 posts debating whether it was actually a hurdle. On Mar 26, 2009, at 2:50 PM, andrey mirtchovski wrote: a straight cocoa drawterm rewrite On Mar 26, 2009, at 3:00 PM, Uriel wrote: A 9vx, p9p or inferno cocoa port is a project that seems fairly I can do one of these; which is the most needed/wanted? If you get one, you should get all. Unfortunately, the code bases for all of these things differ slightly. Some have bugfixes that others don't have. In my mind, 9vx is the most needed / wanted. Others will say Inferno. I think fewer would say p9p. --dho
Re: [9fans] another webfs question
2009/3/27 erik quanstrom quans...@quanstro.net:
It seems I'm hitting this error when sending some GET requests:
In /sys/src/cmd/webfs/url.c:
if(strstr(url, %00)){
werrstr(escaped NUL in URI);
return -1;
}
I haven't fully understood the comment above, especially if it is against
the RFC to have an escaped NUL in an url, but this can actually happen,
at least with queries to a bittorrent tracker. For example when specifying
the info hash of a specific torrent when sending a scrape request:
http://bttracker.debian.org:6969/scrape?info_hash=%F1%AE%D2%E5%15%A0%BD%F1%41%54%9D%44%00%47%AB%97%81%2B%69%16
(13th char in the info hash is a NUL)
I get a reply to that one both with wget on linux or hget on plan 9,
while webfs gives the error from the code above.
So is it webfs that needs fixing for that case, or are the other tools
breaking some RFC with that?
rfc2396 doesn't mention any restrictions; %00 is legal.
Yeah, there aren't any. That's the point of URL encoding; NULL bytes
are as acceptable as any other, and your client should be able to
handle them -- so I think that webfs check is just bogus. It should
just encode it as a \0 and pass it through.
--dho
- erik
Re: [9fans] another webfs question
2009/3/27 erik quanstrom quans...@coraid.com: Yeah, there aren't any. That's the point of URL encoding; NULL bytes are as acceptable as any other, and your client should be able to handle them -- so I think that webfs check is just bogus. It should just encode it as a \0 and pass it through. (you do mean %00 should result in a byte with value 0, not two bytes (in c notation) '\\' and '0', right?) Yes, I meant '\0'. assuming that every application that uses webfs is prepared to handle a null byte in the middle of a string. what webfs does — complaining loudly — is much preferrable to programs misbehaving silently. since it's quite likely that plan 9 applications are not going to properly deal with a null in a string, it's probablly a good implementation strategy unless you're willing to test all the programs that use webfs to make sure that this case is properly handled. Ok, but then valid applications such as this one can't use webfs. I think something needing this could solve the issue by having the application import webfs into its own namespace, and then sending some sort of ctl command telling it to set an option to allow null bytes. --dho - erik
[9fans] Stuck at partdisk
Hey all, Trying to get an updated qemu image out that we can give to SoC students, and I'm having some issues with the installer. I seem to be stuck at the partdisk step. The partition seems to write fine to the disk, but when exiting fdisk, it tells me I'm not finished with partdisk yet. Using an iso that I just downloaded today. Ideas? --Devon
Re: [9fans] Stuck at partdisk
2009/4/5 Devon H. O'Dell devon.od...@gmail.com: Ideas? Works fine if I turn off DMA. --dho
Re: [9fans] Stuck at partdisk
2009/4/5 ron minnich rminn...@gmail.com: On Sun, Apr 5, 2009 at 12:12 PM, Devon H. O'Dell devon.od...@gmail.com wrote: 2009/4/5 Devon H. O'Dell devon.od...@gmail.com: Ideas? Works fine if I turn off DMA. no need to have DMA on on qemu anyway, so you have a workaround. Except that it's now looking to take about 5 hours to install on my 3 core AMD64 box with 8GB RAM :) ron
Re: [9fans] Stuck at partdisk
2009/4/5 ron minnich rminn...@gmail.com: I got confused. The problem you had with dma off was in qemu or on real hardware? Sorry. qemu, but it hardly seems fitting given the beefiness of the machine the emulator's running on. ron
Re: [9fans] Stuck at partdisk
2009/4/5 Bakul Shah bakul+pl...@bitblocks.com: On Sun, 05 Apr 2009 15:54:19 EDT Devon H. O'Dell devon.od...@gmail.com wrote: 2009/4/5 ron minnich rminn...@gmail.com: On Sun, Apr 5, 2009 at 12:12 PM, Devon H. O'Dell devon.od...@gmail.com wr ote: 2009/4/5 Devon H. O'Dell devon.od...@gmail.com: Ideas? Works fine if I turn off DMA. no need to have DMA on on qemu anyway, so you have a workaround. Except that it's now looking to take about 5 hours to install on my 3 core AMD64 box with 8GB RAM :) It is likely a problem with the version of qemu you are running. On freebsd-current with qemu-0.10.1 there is no problem with DMA (just tried with today's ISO). Must be FreeBSD-CURRENT i386, because it sure isn't working on FreeBSD-CURRENT amd64 with a tree I built last night :) --me
Re: [9fans] yet another cheapo mips board
2009/4/7 ron minnich rminn...@gmail.com: Can't remember if this one came up: $59. http://www.ubnt.com/products/rs.php Where do you find it for $59? Cheapest I can find from their page is $69. --dho
Re: [9fans] a bit OT, programming style question
2009/4/9 Richard Miller 9f...@hamnavoe.com: set | wc -l 8047 well. This is nearly as big as the shell itself in the (ahem) good old days. term% tar tzvf interdata_v6.tar.gz bin/sh --rwxr-xr-x 8316 Nov 13 15:48 1978 bin/sh No, it's very likely bigger. wc -l is lines of course, and I'm guessing each line is more than 1 character. However, $ set | wc -l 64 I don't quite get that locally. --dho
Re: [9fans] Help for home user discovering Plan 9
I don't think there are video players. Someone created an ffmpeg port, but I'm not sure if it does video output or just conversion as I've never actually used it. --dho
Re: [9fans] NAT implementation
2009/4/15 Patrick Kristiansen patrick.kasse...@gmail.com: Hello 9fans. I'm thinking of writing a NAT implementation for plan 9. I have searched the archives and I'm not quite sure how to get started. Hi Patrick, As I see it there could be three ways of approaching this: 1. User space implementation using ipmux 2. User space using pkt interfaces in ipifc. 3. Kernel using something like sources/dho/nfil I think #2 would be an easily testable and maybe more `correct' way to do this in Plan 9. I think doing an implementation directly in the IP path is easier, overall, but that's where my experience lies anyway. nfil is horribly broken. I wrote it some years ago when I was first getting into Plan 9, Plan 9's C, and kernel stuff. Also, I wasn't horribly experienced with C at the time either; I think last time I looked at nfil, there were at least several memory leaks. Do you have any advices on how to capture packets and how to send them out again after replacing src/dst addr and port? It's not quite that simple. At the simplest, when the packet goes out, you have to keep a tab of the destination host / port and source host / port. When a packet comes in, you look up the source host / port in the hash table (hashed by dest host / port). You rewrite the packet. You have to regenerate the packet checksum after rewriting it. You send it back out. (If you're doing the rewriting in userland, you may be able to avoid doing a recalculation of the checksum, as the kernel may notice it's bad and re-write it, thinking it's trash). Are there any ways of testing NAT in a virtual machine? Right now I'm using vmware and it would be nice to be able to test it without setting up a real machine with two Ethernet interfaces. Sure, configure a couple VMs with hostonly networking and set up their IP addresses accordingly. -Patrick Kristiansen --dho
Re: [9fans] NAT implementation
2009/4/15 Anthony Sorace ano...@gmail.com: the idea is interesting, but it's a compliment, not a replacement. there's plenty of situations where installing something on all your hosts is either impractical or undesirable; centralizing the work in network infrastructure is often a big win. doing what you describe hits a different set of use cases. This is what I meant to say, expressed in a much nicer, and less asshole-ish fashion. --dho
[9fans] vgadb woes
I've got a laptop that I (for shits and giggles) decided to put Plan 9 on. Lo and behold, it worked fine (Compal EL80, Core 2 Duo, 2GB RAM, nVidia video). So, I'm running at 1280x1024x32 right now in VESA, which is reasonable, but I'd like to run at my maximum native resolution, which is 1680x1050 (I believe). After tooling around with Xorg configs, I've found a horiz/vert refresh rate that should work for me... ...except that I have no idea how to convert that into vgadb lingo. I've read all the comments in vgadb, and the manpage, which helpfully suggests that I purchase a rather dated book. I suppose it's at least available, but in the interest of ``I want it now,'' are there any hints on translating eg. Option DPMS HorizSync 28-84 VertRefresh 43-60 into vgadb(6) lingo? Only other bit of potentially relevant information I have is that Xorg reports the monitor as having a ``330.0 MHz pixel clock''. Thanks, --dho
Re: [9fans] vgadb woes
Thanks for all the tips, I'll see what I can get working (and perhaps flesh out the wiki once it's working well, if it ends up being different from what's already there). --dho
Re: [9fans] vgadb woes
Well, that ends up getting my screen to have a bunch of lines through it, staggered -- so I'm not much better off than I was before. I'm guessing that's an nVidia driver issue or something. If I had any idea about video devices, I'd try to fix it, but I don't. I'll just live with a bit low-res VESA for now (all of the VESA modes don't seem to work), unless someone has ideas. Thanks! --dho
Re: [9fans] web server
2009/4/16 Rudolf Sykora rudolf.syk...@gmail.com: Hello, I've been wondering (and not reading much)... If I'd like to use plan9 as a www server, is there anything ready? Yes, there is a pre-built httpd and libraries for writing your own. Recent apache probably doesn't compile in APE (but maybe it does). How difficult would it be to use rails or merb in plan9? Is it feasible? Very difficult. No, not feasible. You would have to port Ruby. And then possibly rails, too. Plan 9 isn't UNIX, or UNIX-like, or POSIX (or POSIX-like). APE helps with some stuff, but not all the way. thanks ruda --dho
[9fans] security questions
In the interests of academia (and from the idea of setting up a public Plan 9 cluster) comes the following mail. I'm sure people will brush some of this off as a non-issue, but I'm curious what others think. It doesn't seem that Plan 9 does much to protect the kernel from memory / resource exhaustion. When it comes to kernel memory, the standard philosophy of ``add more memory'' doesn't quite cut it: there's a limited amount for the kernel, and if a user can exhaust that, it's not a Good Thing. (Another argument I heard today was ``deal with the offending user swiftly,'' but that does little against full disclosure). There are two potential ways to combat this (though there are additional advantages to the existence of both): 1) Introduce more memory pools with tunable limits. The idea here would be to make malloc() default to its current behavior: just allocate allocate space from available arenas in mainmem. An additional interface (talloc?) would be provided for type-based allocations. These would be additional pools that serve to store specific kernel data structures (Blocks, Chans, Procs, etc.). This provides two benefits: o Protection against kernel memory starvation by exhaustion of a specific resource o Some level of debugalloc-style memory information without all of the overhead I suppose it would be possible to allow for tunable settings as well by providing a FS to set e.g. minarea or maxsize. The benefit to this approach is that we would have an extremely easy way to add new constraints as needed (simply create another tunable pool), without changing the API or interfering with multiple subsystems, outside of changing malloc calls if needed. The limits could be checked on a per-process or per-user (or both) basis. We already have a pool for kernel memory, and a pool for kernel draw memory. Seems reasonable that we could have some for network buffers, files, processes and the like. 2) Introduce a `devlimit' device, which imposes limits on specific kernel resources. The limits would be set on either a per-process or per-user basis (or both, depending on the nature of the limit). #2 seems more like the unixy rlimit model, and the more I think about it, the less I like it. It's a bit more difficult to `get right', it doesn't `feel' very Plan 9-ish, and adding new limits requires more incestuous code. However, the limits are more finely tuned. Just wondering any thoughts on this, which seems more feasible, if anybody would feel it's a `good idea,' and the like. I got mixed (though mostly positive from those who understood the issue) feedback on IRC when I brought up the problem. I don't have any sample cases in which it would be possible to starve the kernel of memory. --dho
Re: [9fans] Rails? (was Re: web server)
2009/4/16 hiro 23h...@googlemail.com: What is the advantage of rails anyway? I had a quick glance, but still don't really understand it's function. MVC development model. Allows you to abstract the data from the code from the design, but easily access needed parts from other needed parts. One of the big things here is the ORM, which basically maps information in a database to native language objects. --dho
Re: [9fans] security questions
2009/4/16 Venkatesh Srinivas m...@acm.jhu.edu:
Devlimit / Rlimit is less than ideal - the resource limits aren't
adaptive to program needs and to resource availability. They would be
describing resources that user programs have very little visible
control over (kernel resources), except by changing their syscall mix
or giving up a segment or so. Or failing outright.
Right, but that's part of the point. They have very little visible
control over said resources, but the kernel does need to impose
limitations on the allowable resources, more below. Either way, I
agree. This form of resource limitation sucks. My reasoning is
different, however: I feel that the number of places you need to add
new code and verify that any future changes respect these sorts of
limitations. This is much more difficult to do than when the
limitation is built into the allocator.
Prohibitions per-user are kinda bad in general - what if you want to
run a potentially hostile (or more likely buggy) program? You can
already run it in its own ns, but having it be able to stab you via
kernel resources, about which you can do nothing, is bad.
This depends on your perspective. If you are an administrator, and you
are running a system that provides access to a plethora of users, your
viewpoint is different than if you are a programmer, writing an
application with expensive needs. A user who wants to run a
potentially hostile program should not be able to affect the system to
the point that other users have their own negative experiences. A user
running a buggy program that hogs a ton of memory is not such a big
deal. Buy more memory. A user running a buggy program that runs the
kernel out of resources, causing it to halt is a big deal.
The typed allocator is worth looking at for speed reasons - the slab
allocator and customalloc have shown that its faster (from the
perspective of allocation time, fragmentation) to do things that way.
But I don't really see it addressing the problem? Now the constraints
are per-resource, but they're still magic constraints.
This is the pitfall of all tunables. Unless someone pulls out a
calculator (or is mathematically brilliant), figuring out exact
numbers for X number of R resources spread between N users on a system
with Y amount of memory is silly.
Fortunately, an administrator makes educated best guesses based upon
these same factors:
1) The expected needs of the users of the system (and in other cases,
the absolute maximum needs of the users)
2) The limitations of the system itself. My laptop has 2GB of RAM, the
Plan 9 kernel only sits in 256MB of that. Now, assuming I have a
program that's able to allocate 10,000 64 byte structures a second, I
can panic the system in under two minutes. Does that mean I want to
limit my users to under 10,000 of those structures? Not necessarily,
but if I expect 40 users at a given time, I might want to make sure
that number is well under 100,000.
While it may not be perfectly ideal, it allows the administrator to
maintain control over the system. Additionally, there's typically
always a way to turn them off (echo 0 /dev/constraint/resource,
hypothetically speaking). In this respect, I don't see how it doesn't
address the problem...
...Unless you consider that using Pools for granular limitations isn't
the best idea. In this light, perhaps additional pools aren't the
correct answer. While creating an individual pool per limited resource
serves to implement a hard limit on that resource, it's also required
to have a maximum amount of memory. So if you ditch that idea and just
make typed allocations, the problem is `solved':
When an allocation takes place, we check various heuristics to
determine whether or not the allocation is valid. Does the user have
over X Fids? Does the process hold open more than Y ports?
If these heuristics fail, the memory is not allocated, and the program
takes whatever direction it takes when it does not have resources.
(Crash, complain, happily move forward, whatever).
If they pass, the program gets what it needs, and {crashes, complains,
happily moves forward}.
One can indirectly (and more consistently) limit the number of
allocated resources in this fashion (indeed, the number of open file
descriptors) by determining the amount of memory consumed by that
resource as proportional to the size of the resource. If I as a user
have 64,000 allocations of type Foo, and struct Foo is 64 bytes, then
I hold 1,000 Foos.
The one unfortunate downside to this is that implementing this as an
allocation limit does not make it `provably safe.' That is to say, if
I create a kernel subsystem that allocates Foos, and I allocate
everything with T_MANAGED, there is no protection on the number of
Foos I allocate (assuming T_MANAGED means that this is a memory
allocation I manage myself. It's therefore not provably safer, in
terms of crashing the kernel, and I haven't been able to come up with
an idea that is provably safe (unless type
Re: [9fans] security questions
One can indirectly (and more consistently) limit the number of allocated resources in this fashion (indeed, the number of open file descriptors) by determining the amount of memory consumed by that resource as proportional to the size of the resource. If I as a user have 64,000 allocations of type Foo, and struct Foo is 64 bytes, then I hold 1,000 Foos. And by this, I clearly mean 64,000 bytes of allocated Foos. --dho
Re: [9fans] security questions
2009/4/16 erik quanstrom quans...@quanstro.net: have you taken a look at the protection measures already built into the kernel like smalloc? At least in FreeBSD, you can't sleep in an interrupt thread. I suppose that's probably also the case in Plan 9 interrupt handlers, and this would mitigate that situation. While it may not be perfectly ideal, it allows the administrator to maintain control over the system. being a system adminstrator, i dislike any ideas that require extra adminstration. for the same reason, content-based email filters are impossible to maintain yourself. you can't keep up with the threats. There is that sentiment as well. I'm writing the code anyway, because at least the API implementation is smaller than the amount of text in emails I've already written about it (not to mention IRC discussion). I tend to feel like there should be reasonably large defaults so that you don't have to muck with it. Or maybe it's turned off by default. I don't know. Either way, I'm not particularly expecting it to be accepted as a patch, but I'm willing to be pleasantly surprised. Besides, I haven't touched my sources tree for a good two years. It needs something fresh :). otoh, if you panic because you run out of resources or whatever, the consequence should be a reboot. at most you loose some editor state and need to spend a few minutes logging back in. Depends again on the application. If you're talking about a terminal, yes. If you're talking about a CPU server where someone is working on code, someone else is writing a presentation, and yet another person is in the middle of a video transcode, you're talking about a lot of wasted time, potentially. if you allow users to log into your fileserver, you're asking for trouble. Fileserver, I agree. I don't think a sane person would allow `untrusted' user access, let alone anonymous access.. On a CPU server, you kind of have to allow access to potentially untrusted users. That's kind of the definition. (Hell, even paying users aren't necessarily trustworthy. Tons of web hosts get exploited each year by paying customers). the one resource that does need some fancier managment is procs. the problem is that out-of-processes tends to act like livelock. it would probablly be an improvement to set ooprocs variable when out of procs and clear it when some fraction (say 1/10) becomes free. then one could panic if the out-of-processes condition persists for, say, 30 seconds. Maybe I'll look at that after this. (i haven't had this problem since i added some better spam filtering.) - erik Thanks for your insight so far, in any case :) --dho
Re: [9fans] security questions
2009/4/16 erik quanstrom quans...@quanstro.net: On Thu Apr 16 17:51:42 EDT 2009, devon.od...@gmail.com wrote: 2009/4/16 erik quanstrom quans...@quanstro.net: have you taken a look at the protection measures already built into the kernel like smalloc? At least in FreeBSD, you can't sleep in an interrupt thread. I suppose that's probably also the case in Plan 9 interrupt handlers, and this would mitigate that situation. plan 9 doesn't have interrupt threads, but that's beside the point. interrupts are driven by the hardware, not users. so smalloc, which is used to allow user space to wait for memory if it is not currently available doesn't make any sense. My misunderstanding then, as smalloc is available in port/alloc.c, which is also compiled into the kernel. I'm not concerned about oom conditions in userland. having the potential for running out of memory in an interrupt handler might be a sign that a little code reorg is in order, if you are worried about this sort of thing. (and even if you're not.) The potential for running out of memory in an interrupt handler exists if a user has found a way to consume kernel resources from userland and the interrupt needs to allocate that extra 1 byte. in any event, i think there is more code to deal with these problems in the kernel that first meets the eye. much of it is small and, if you're not looking for it, easy to miss. I don't think so. You can get very specific about the problem or you can get very generic. This is a generic implementation that would allow for dealing with such problems as they arise, and actually dealing with them in an easy, extensible fashion, without having to add huge support code diffs for calculation of every resource you're tracking (as is the case with rlimits, which require you to add functions for each limit, hooks everywhere you want to track them, shell support, and sysctls). From a codebase perspective, it's not a lot more code than you'd think. It's very little code so far, and I'm about halfway finished with the support part. Initial implementation will probably be suboptimal, but I think useful for proof of concept. Identifying the areas that need attention is the difficult part, but I'll address that further down. Depends again on the application. If you're talking about a terminal, yes. If you're talking about a CPU server where someone is working on code, someone else is writing a presentation, and yet another person is in the middle of a video transcode, you're talking about a lot of wasted time, potentially. and potentially, i could win the lottery. ☺. And potentially, this code would go into Plan 9. ☺ ☺ ☺. I think those chances are a little smaller. Fileservers and terminal servers, I don't think this is a big issue. CPU servers, I think it is. I'm considering setting up a public Plan 9 cluster, though however useless/useful it is to be remains to be seen. Part of the purpose of this endeavor is to find exactly these kind of conditions. Whether anybody is interested remains to be seen, but perhaps some incentives can be provided. I don't know. i have had exactly 1 out-of-resource reboot in the last 18 months. without real data on what and where the problems are, i would think this would become a difficult issue. I don't know what your use case is, though I know that you probably use the system more heavily than I. I think with people trying to find issues, it could be a much easier endeavor, and I think it's a fun one to address. The fact that there was one proves that these issues can occur theoretically. All it needs is identification and reproduction. We're shielded in part by our small userbase and relative lack of interest in examining code and auditing. But that's not security. - erik --dho
Re: [9fans] security questions
2009/4/16 erik quanstrom quans...@quanstro.net: My misunderstanding then, as smalloc is available in port/alloc.c, which is also compiled into the kernel. I'm not concerned about oom conditions in userland. smalloc is used in the kernel, but only when running with up (user process) and only when dealing with a user's data. for example, when gathering up the response to a read on /proc/%d/regs or whatever. interrupts are quite different. there are lots of things that are a bad idea in interrupt context. but one can wakeup a kernel proc that's sitting there waiting to deal with all the hair. Right, we're saying the same thing backwards. I just am not sure why smalloc was brought up. Yes, it is able to sleep until memory is available for the operation, but it's not used *everywhere*. having the potential for running out of memory in an interrupt handler might be a sign that a little code reorg is in order, if you are worried about this sort of thing. (and even if you're not.) The potential for running out of memory in an interrupt handler exists if a user has found a way to consume kernel resources from userland and the interrupt needs to allocate that extra 1 byte. doctor, doctor it hurts when i do this! there's a simple solution. never allocate in interrupt context. i haven't ever felt the need to allocate in interrupt context. in fact drivers like 82598 or the myricom driver never allocate during operation. It was a point, not an argument. You're dismissing it altogether, I'm saying that it's a potential issue. No, I haven't read the interrupt code for every driver. It could be a complete non issue, and it probably is. I'm just discussing it :). in any event, i think there is more code to deal with these problems in the kernel that first meets the eye. much of it is small and, if you're not looking for it, easy to miss. I don't think so. are you telling me this code is not there, or that you've seen all of it? I think we have a miscommunication, because you cut out the rest of the context of my explanation, so I don't know how to address your question. Neither; it wasn't the point I was making. i have had exactly 1 out-of-resource reboot in the last 18 months. without real data on what and where the problems are, i would think this would become a difficult issue. I don't know what your use case is, though I know that you probably use the system more heavily than I. I think with people trying to find issues, it could be a much easier endeavor, and I think it's a fun one to address. i have 35 people working hard to kill the systems with 700MB mailboxes, and other tricks. Which is more heavily than I, as I thought :) but what they aren't doing is writing fork bomb programs or programs that fuzz device drivers. Right, and that's a real threat. We're shielded in part by our small userbase and relative lack of interest in examining code and auditing. But that's not security. i could argue that what you're looking into isn't the type of security that plan 9 has ever provided. i think the assumption has been that the environment has been a work group and there aren't any hostile users. there are lots of problems when you move away from that assumption. Yes, there are, but it doesn't mean that it's an invalid assumption. If you're arguing that my point is invalid because it's not a proper application of Plan 9, I'd argue that Plan 9 isn't fit for the Internet, where there are malicious users and script kiddies. That said, I don't disagree. Perhaps Plan 9's environment hasn't been assumed to contain malicious users. Which brings up the question: Can Plan 9 be safely run in a potentially malicious environment? Based on this argument, no, it cannot. Since I want to run Plan 9 in this sort of environment (and thus move away from that assumption), I want to address these problems, and I kind of feel like it's weird to be essentially told, ``Don't do that.'' If you don't want to run Plan 9 there, ok. Maybe I'm the only one on the list who does. Maybe someone will come out later who also wants to. Either way, the code is in development, and I'm going to finish it. Don't use it if you don't want to :) i would think the *first* order of business would be to encrypt all traffic to the fs so users can't use snoopy to captures other user's fs traffic This is another serious issue. Perhaps I'll tackle it next. - erik --dho
Re: [9fans] security questions
2009/4/16 erik quanstrom quans...@quanstro.net: Right, we're saying the same thing backwards. I just am not sure why smalloc was brought up. Yes, it is able to sleep until memory is available for the operation, but it's not used *everywhere*. that's part of my point. sometimes smalloc is appropriate, sometimes it is not. it depends on other things than just what you are going to use the allocation for. do you have a particular, concrete example? No, you brought it up first, asking if I had looked at it. I think this particular thread of discussion is agreed upon and tangential. but what they aren't doing is writing fork bomb programs or programs that fuzz device drivers. Right, and that's a real threat. but you can't defend against it unless you decide you can have exactly n processes per system and each one can have 1/n * userlandsize bytes of memory. you could divvy up memory by user to be a little bit more flexable, but providing hard guarantees is going to be very limiting. Yeah, that's part of the reason I posted here, was to see if other people had different ideas. This usually isn't a bad place to pull in thoughts and solutions. And of course processes aren't the only `potential evil.' I agree that my solution may not be the best one. But I can't come up with anything better right now, and at least this seems semi-Plan-9-ish. don't forget about the stack overcommitment issue. Heh. Yes, there are, but it doesn't mean that it's an invalid assumption. If you're arguing that my point is invalid because it's not a proper application of Plan 9, I'd argue that Plan 9 isn't fit for the Internet, where there are malicious users and script kiddies. i just stated what i thought the historical situation was. the point was only that changing direction will be difficult. This thread certainly proves that :) i don't think the second part of your argument holds. defending from a local threat (like a fork bomb) is much different from defending against script kiddies. it's also much harder. also, script kiddies don't do a good job of targeting plan 9. Point taken. If you don't want to run Plan 9 there, ok. Maybe I'm the only one on the list who does. Maybe someone will come out later who also wants to. if i didn't think this could be useful, i wouldn't bother replying. Point taken :). So are there other / better ideas? Did anybody else read that paper about Viengoos? - erik --dho
Re: [9fans] security questions
2009/4/16 Bakul Shah bakul+pl...@bitblocks.com: On Thu, 16 Apr 2009 21:25:06 EDT Devon H. O'Dell devon.od...@gmail.com wrote: That said, I don't disagree. Perhaps Plan 9's environment hasn't been assumed to contain malicious users. Which brings up the question: Can Plan 9 be safely run in a potentially malicious environment? Based on this argument, no, it cannot. Since I want to run Plan 9 in this sort of environment (and thus move away from that assumption), I want to address these problems, and I kind of feel like it's weird to be essentially told, ``Don't do that.'' Why not give each user a virtual plan9? Not like vmware/qemu but more like FreeBSD's jail(8), done more elegantly[TM]! To deal with potentially malicious users you can virtualize resources, backed by limited/configurable real resources. I saw a talk about Mult at DCBSDCon. I think it's a much better idea than FreeBSD jail(8), and its security is provable. See also: http://mult.bsd.lv/ I do like this idea. The other thought that comes to mind is to consider something like class based queuing (from the networking world). That is, allow choice of different allocation/scheduling/resource use policies and allow further subdivision. Then you can give preferential treatment to known good guys. Other users can still experiment to their heart's content within the resources allowed them. My point being think of a consistent high level model that you like and then worry about implementation details. That's also another interesting idea I hadn't considered. Anybody else with thoughts on these? --dho
Re: [9fans] security questions
2009/4/17 Bakul Shah bakul+pl...@bitblocks.com: On Thu, 16 Apr 2009 22:19:21 EDT Devon H. O'Dell devon.od...@gmail.com wrote: 2009/4/16 Bakul Shah bakul+pl...@bitblocks.com: Why not give each user a virtual plan9? Not like vmware/qemu but more like FreeBSD's jail(8), done more elegantly[TM]! To deal with potentially malicious users you can virtualize resources, backed by limited/configurable real resources. I saw a talk about Mult at DCBSDCon. I think it's a much better idea than FreeBSD jail(8), and its security is provable. See also: http://mult.bsd.lv/ But is it elegant? Rather. [Interviewer: What do you think the analog for software is? Arthur Whiteny: Poetry. Interviewer: Poetry captures the aesthetics, but not the precision. Arthur Whiteny: I don't know, may be it does. -- ACM Queue Feb/Mar 2009, page 18. http://mags.acm.org/queue/20090203] Perhaps Plan9's model would be easier (and more fun) to extend to accomplish this. One can already have a private namespace. How about changing proc(3) to show only your login process and its descendents? What if each user can have a separate IP stack, separate (virtualized) interfaces and so on? But you'd have to implement some sort of limits on oversubcribing (ratio of virtual to real resources). Unlike securitization in the hedge fund world.
Re: [9fans] security questions
2009/4/17 erik quanstrom quans...@quanstro.net: What if each user can have a separate IP stack, separate (virtualized) interfaces and so on? already possible, but you do need 1 physical ethernet per ip stack if you want to talk to the outside world. I'm sure it wouldn't be hard to add a virtual ``physical'' interface, even though that seems a little bit pervasive, given the already semi-virtual nature due to namespaces. Not sure how much of a hassle it would be to make multiple stacks bindable to a single interface... but perhaps that's the better way to go? But you'd have to implement some sort of limits on oversubcribing (ratio of virtual to real resources). Unlike securitization in the hedge fund world. this would add a lot of code and result in the same problem as today — you can be run out of a criticial resource. Oversubscribing is the root of the problem. In fact, even if it was already done, on a terminal server, imagmem is also set to kpages. So if someone found a way to blow up the kernel's draw buffer, boom. I don't know how far reaching that is, as I've never really seen the draw code. Unfortunately, that's what you have to do unless you can afford to invest in more hardware, or have a small userbase. Or find some middle ground -- and maybe that's what the `virtualization' would address. - erik --dho
Re: [9fans] web server
2009/4/17 Rudolf Sykora rudolf.syk...@gmail.com: Writing the core of a blog engine in three lines of rc is hard to beat, plus you get the benefit of being able to manipulate and manage all your data using the tools any self respecting Unix user loves. uriel well, I haven't thought about it deeply yet, but what I guess could be a problem with your approach is that many features would have to be somehow implemented first so that it all be useable. I mean e.g. ajax style of page content refresh, session management, perhaps POST method too. Not really. There's nothing magical about AJAX. It's just HTTP requests. As long as you support those, your pages can use AJAX. --dho ruda
Re: [9fans] a bit OT, programming style question
Wait, am I on the wrong mailing list? Since when was this Fans of BSD and Linux Talk about why Plan 9 Sucks Donkey Shit? (I use FreeBSD and Linux. OTOH, I'm not on freebsd-general@ and centos mailing lists talking about how our private namespaces and 9p are so much shinier than VFS)
Re: [9fans] Help for home user discovering Plan 9
2009/4/17 Eris Discordia eris.discor...@gmail.com: It's like I'm seeing an apparition of myself back more than a year ago. No wonder 9fans got to dislike me so much. Do 9fans get nuisances like me in regular intervals? From time to time :) We have a high conversion rate, though. --dho
[9fans] Security, take 2.
Given the feedback from the list, I've come up with two alternatives.
(Well, one of them was actually Mechiel's brainchild).
Idea #1 (From Mechiel)
Instead of doing typed allocations, give every user an allocation
pool, from which all kernel allocations will take place. To extend on
this, the size of the pool is somewhat dynamic -- as new users log in,
all users' ability to consume kernel resources goes down by a fair
percentage. (Except for eve.) As users log out, all users gain the
percentage of resources back. The number is based on a 90% resource
allocation -- i.e. the kernel may keep 10% of its initial resources
for things it needs to do all by itself, without users interfering.
When a malloc occurs with up, that size is stored in a counter. The
proc also holds per-proc information, so that a username change can
intelligently move only the resources from that proc over to the new
user, instead of everything from the old user (which is clearly
wrong).
This implementation has one magic number: 0.9. The fair share is
percentage based from that, but I'm not experience in fair share
algorithms, so maybe there's a better way to do that. Also, the
security of this implementation is provable.
Downside is that this implementation is somewhat intrusive:
introducing 9/port/kreslimit.c and touching 9/port/portdat.h,
9/port/portfns.h, 9/port/alloc.c, 9/port/proc.c, and 9/port/devcap.c
I only have one question about implementation: where in process
creation is the process username set? In newproc(), I see p-user set
to *nouser; I can only assume this is `fixed' later, but I don't
know where. I ask, because for natively started processes (i.e. not a
user logging in from drawterm, that's handled through devcap), I need
to incref on the proc structure that holds the user's pool info. I
know I need to do this in e.g. #c/user, and devcap. But when a user
starts a new process after logging in, it needs to add a ref. Where in
proc.c (or elsewhere) is it finally determined who the user is? (Is
that in renameuser()? I wasn't sure).
Idea #2
Implement a similar thing as mult.bsd.lv. This would be implemented as
a device and would give you a `blank' Plan 9 system:
echo {cpushare} {maxmem} {newroot} /dev/virtual/new
I haven't thought a whole lot about how this would work, but I'm
guessing at least the maxmem would be implemented similarly, by
creating a new pool. I'd have to learn more about the scheduler to do
the CPU limiting, and newroot would be as easy as a bind(). This would
also be somewhat intrusive (but maybe not more so than Kreslimit), but
has hard values, and provable security. (And the advantage of being
able to spawn `new' Plan 9 instances from Plan 9.) More like jail(8)
in FreeBSD (but much cleaner, due to its provability), less like
vkernel(8) in DragonFly BSD.
--dho
Re: [9fans] VMs, etc.
2009/4/20 erik quanstrom quans...@quanstro.net: i'm not following along. what would be the application? Jukebox, perhaps? - erik
[9fans] Really weird SATA disk/controller issue
Hey all, That laptop that I was boasting ran Plan 9 flawlessly (minus the non-native graphics) is now exhibiting some really weird behavior. I've replaced the old Hitachi Travelstar disk (100GB / 7200RPM) with a Seagate 320GB disk (5400RPM). I can install FreeBSD and CentOS fine. When I try to install Plan 9 onto this new disk, I get really weird I/O errors now. If I try to delete labels / partitions, it goes wacky with I/O errors on what seems to be the second disk operation I do from the menu, with a caveat: o If I go from a blank disk, I can get to copydist before it gives me an I/O error on every block copy. o If I go from a disk that had a failed install, I can delete the labels (9fat, nvram, fossil, swap), but if I then try to delete the partition, I get an I/O error. Sometimes I can get to fmtfossil from here, but that will always give me an I/O error if I start from this state. o If I go from a disk that had a failed install, and delete the partitions, I try to delete labels later, I get an I/O error when trying to write the labels. It still works fine on the old 100GB disk. I've experimented with various sizes, and installing it after other operating systems, to no avail. Why should the disk matter? --dho
Re: [9fans] (no subject)
2009/4/23 Charles Forsyth fors...@terzarima.net: lcc is nothing like as hard to compile as gcc (which has got worse, much worse, over the years). funnily enough, my gcc bootstrap compilation is still going (on a multi-core linux machine). it started over an hour ago. bizarre. (my apologies for diverging the topic from both Plan 9 and the original question) What languages are you compiling? on my 3-core amd processor, it takes 10 minutes to compile c and c++. Steve: I know there are some really good resources about PE online, as well as several on MSDN that might contain more information about what Windows will actually do with a PE. I don't believe they are required to be relocatable, as even Windows 7 will still run Win9x binaries, and I'm fairly sure that there wasn't the ability to relocate executables back then. --dho
[9fans] IWP9 this year?
Hello! Although I probably won't be able to go unless it's close (a.k.a. in the Baltimore / Washington DC area -- which actually isn't perhaps a bad idea?), the subject of an IWP9 has been brought up several times this year. I'd like to get the ball rolling on this, in case anybody is interested in setting it up or attending. I think the question at this point is, ``Who wants to organize it, and who will attend?'' I'm perfectly fine to organize the event, and I'm sure my office could more than accommodate any interested attendees. Just kind of curious what timeframes people would be interested in, and whether people would be able / willing to come. If not, some discussion on the when and where might not be a bad idea, anyway. Let me know! --Devon
Re: [9fans] IWP9 this year?
2009/4/24 erik quanstrom quans...@quanstro.net: On Fri Apr 24 09:56:24 EDT 2009, devon.od...@gmail.com wrote: Hello! Although I probably won't be able to go unless it's close (a.k.a. in the Baltimore / Washington DC area -- which actually isn't perhaps a bad idea?), the subject of an IWP9 has been brought up several times this year. I'd like to get the ball rolling on this, in case anybody is interested in setting it up or attending. I think the question at this point is, ``Who wants to organize it, and who will attend?'' I'm perfectly fine to organize the event, and I'm sure my office could more than accommodate any interested attendees. Just kind of curious what timeframes people would be interested in, and whether people would be able / willing to come. If not, some discussion on the when and where might not be a bad idea, anyway. Let me know! --Devon i have offered to host this year in athens, ga, home of many things, including coraid, inc. and the univeristy of georga. there should be plenty of accomidations. we are about 40 minutes outside atlanta, ga so it's pretty easy to get to — at least from the airport. Ok, I hadn't seen that. Similarly, I'm in Columbia, MD, which is about 15 minutes from both BWI and Reagan Int'l airports (Dulles is a bit of a hike; perhaps more towards 40 minutes), and there are many Amtrak stations around. Home of Message Systems (where I work, though we don't do anything interesting with Plan 9 except listen to me proselytize it), and a short distance away from the ``Nation's best Crab'' (I think that's what Baltimore is calling it) and Capitol. i was thinking about 22-24 october 2009. there was some discussion of changing the format to include some workshop this year. i would like to do that, but it's not clear to me what the format should be. i would imagine the workshop would start a few days before the 22 with prep taking place throughout the summer. since many of the likely workshop participants are doing gsoc, perhaps the workshop can be some hands-on with the summer's work and we can expect papers from them, too as well as the usual suspects. :-) if we can agree on that, i'd enjoy doing it. I like that format; I was thinking it would be good to see some of these projects have presentations as well. Additionally, October is sufficiently far in the future that it should work out rather well. I could probably make it down to ATL; would probably only be a 3-or-so hour flight. If you need any help with planning / logistics, that's fine. If people would rather do it here, that's fine. If nobody needs me to do anything, that's fine too, just trying to get the ball rolling :) - erik --dho
[9fans] IWP9 Logistics Poll
I made a logistics poll form based on all the ideas presented thus far. It would be great if you guys could fill it in, there's like 6 questions and a comment field, so it should only take about 1 minute total. Just trying to get a brief and centralized overview of what everyone's personal situation looks like so I can either pass that information off to someone who can start planning if the consensus ends up being it shouldn't be here (MD), or start planning myself. http://206.71.190.158/~dho/iwp9pref.html Would be much obliged if everyone (interested or not) could take time to fill this out. Thanks! --dho
Re: [9fans] creating my own bootable plan9 iso
2009/5/19 rsbohn rsb...@gmail.com: On May 15, 2:52 am, st...@quintile.net (Steve Simon) wrote: Anyone got a script to generate a bootable plan9.iso cdrom image, the mkfiles in /sys/lib/dist seem quite labs-specific. -Steve maht has some details on this. The stuff in /sys/lib/dist is indeed very specific (I was asking this a while ago -- and I never got anything put together that actually worked!) to the Labs, which is somewhat unfortunate. I hate being negative towards the Labs, and I know it isn't that difficult to put a CD together, but it would really be nice to have some of the curtains pulled, because it's not straightforward from the getgo. `Everything' is explained here: http://maht0x0r.blogspot.com/2009/01/plan9-boot-cd.html http://maht0x0r.blogspot.com/2007/11/roll-your-own-plan9-iso.html http://maht0x0r.blogspot.com/2007/10/roll-your-own-plan-9.html --dho
Re: [9fans] new usb implementation
2009/5/26 ge...@plan9.bell-labs.com: I've just pushed out to sources a new USB implementation, courtesy of nemo, who debugged and repaired our old UHCI and OHCI drivers, wrote a new EHCI driver for USB 2, converted the user-mode drivers in /bin/usb and tested it all, among other things. Thank you, nemo. I've updated on sources at least /386/9*load* (though they contain no USB code), /386/9pc*, kernel sources, manual pages and a few scripts in /rc/bin. Tomorrow's CD image should incorporate all this. devusb has a new interface, so it is named #u, to distinguish it from the old one, #U. If usbd is compiled into /boot, /boot/boot will run usbd at start up, thus permitting the use of USB keyboards, mice, disks, etc. at boot time. Sweet! Thanks, guys!
Re: [9fans] Google finally announces their lightweight OS
2009/7/8 erik quanstrom quans...@coraid.com: you say I think, Google did not choose Plan 9 due lack of device drivers, poor IPv6 support and confusing redundant fragment of code lurking around in /sys/boot or 9load, but a compared with Linux a compact, clean and much more efficient FreeBSD could definitely have been a better choice. but then But that's [linux] still a huge hog and spaghetti code; needs a lot of cleanup, which I don't think is going to happen in the near future. i think you're going to have to pick a lane. I don't think so. We already have IPv6 support and it's not that bad. Having more drivers and supported commodity architectures would be a good thing. I'd love to do this, but I don't think anybody's going to match my salary to port drivers, do ACPI, add amd64 support for workstations, etc. I don't think that adding drivers would make it a `huge hog' or require `spaghetti code'. (Linux kernel code isn't really `spaghetti code', it's just poorly organized and some of the architectural decisions, I'd classify as `spaghetti architecture' -- once you find it though, the code isn't so bad to read, in general). and having fought with both the linux and plan 9 boot process, i can assure you that the plan 9 boot process is simplier and more straightfoward. /sys/boot is trivial compared to a linux initrd. I can stand up for this statement. Not only is it trivial compared to initrd, the following of the boot process is much easier. I was doing some work on an ARM architecture port for Plan 9 (for an already dead product, the Siemens SimPAD). Figuring out where the *(#Q*(#...@$ source for the boot stuff was in Linux was a huge hassle and took me days. - erik
[9fans] Fonts
I have very little idea about these fuckers. I know there are baselines and ideas about m's and n's and kerning and whatnot. But how do you make them? I played with some TTF font generators about 10 years ago that I'm sure I illegally obtained somehow, but I realize that I have zero idea of how fonts are designed and packaged. Does anybody know anything about how fonts are created and packaged (info on subfonts would be great, info on TTF would be interesting). --dho
Re: [9fans] Google finally announces their lightweight OS
2009/7/8 erik quanstrom quans...@coraid.com: But don't underestimate the value of the interesting ideas in the linux kernel that get the performance, e.g. RCU. I don't think there are any OSes that have scaled to 4096 CPUs at this point besides Linux. i thought that massively parallel harvard-arch machines had generally fallen out of favor in favor of blue gene-style hardware. is this incorrect? I think it depends on the application. I have a friend who studies fluid dynamics for scramjets and he was mentioning how doing some of those calculations requires ultra-low latency. The algorithms they need to use require multiple passes, and each calculation is affected by surrounding `blocks.' With infiniband and whatnot, this might be moot (he's doing his stuff on 32-core systems right now, so it's not even to that degree), but perhaps there are still applications that still significantly benefit from that architecture. They are quite the opposite of `embarrassingly parallel' problems (a la distributed.net / SETI / Folding). That said, I have no idea what the performance / latency characteristics are of a system with 32 cores and 32 CPUs connected with infiniband / some other proprietary high speed interconnect, or what that would look like performance-wise if it was scaled to 4096 cores versus quad-CPU boards with interconnects. - erik -dho
Re: [9fans] Google finally announces their lightweight OS
2009/7/8 erik quanstrom quans...@coraid.com: I'd love to do this, but I don't think anybody's going to match my salary to port drivers, do ACPI, add amd64 support for workstations, etc. i told myself this for years. it turns out to be a mistaken idea. now that i know, i regret the years i spent doing other things. I certainly don't know anybody who is hiring people to do this sort of work in Plan 9. - erik --me
Re: [9fans] Google finally announces their lightweight OS
2009/7/8 Uriel urie...@gmail.com: On Wed, Jul 8, 2009 at 6:56 PM, Devon H. O'Delldevon.od...@gmail.com wrote: I don't think so. We already have IPv6 support and it's not that bad. Having more drivers and supported commodity architectures would be a good thing. I'd love to do this, but I don't think anybody's going to match my salary to port drivers, do ACPI, add amd64 support for workstations, etc. ACPI will never, ever, ever happen, so people better get over it (and if anyone is naive enough to waste their time trying, it will end up as a useless atrocious mess that wont boot even in a 100th of the systems out there, much less suspend or do anything useful). ACPI support doesn't need to suspend or do thermal zones. It just needs to be able to read the ADT and get MP / interrupt routing table information. This is doable. Have you ever read any of the ACPI spec? I have. As for amd64, it is already done, we are just not worthy to have access to it. Without this getting into a holy war, what Geoff told me was that the amd64 work was for headless CPU servers, which is only mildly useful to me anyway. uriel
Re: [9fans] Google finally announces their lightweight OS
2009/7/8 Uriel urie...@gmail.com: On Wed, Jul 8, 2009 at 9:56 PM, Devon H. O'Delldevon.od...@gmail.com wrote: ACPI support doesn't need to suspend or do thermal zones. It just needs to be able to read the ADT and get MP / interrupt routing table information. This is doable. Have you ever read any of the ACPI spec? I have. The spec doesn't matter much, given that most BIOS out there totally ignore it. I think you're unfamiliar with the spec as it relates to what I mentioned. --dho
Re: [9fans] Google finally announces their lightweight OS
2009/7/8 Benjamin Huntsman bhunts...@mail2.cu-portland.edu: Without this getting into a holy war, what Geoff told me was that the amd64 work was for headless CPU servers, which is only mildly useful to me anyway. If it was released perhaps somebody would add the missing drivers, who knows... As things stand, we will never know. Speaking of the amd64 port, I had thought that Bell Labs was planning on releasing it at some point in the future, but that it currently wasn't quite perfect and they didn't want to have to field complaints... I can't say that I blame them... My understanding from Geoff was exactly this. But I don't want to speak for him or introduce this as fact. I'm unaware of the exact status at this particular time. But, it would be nice to see eventually. Are there plans to let the amd64 port out of the labs at some point in the future? Agreed. Many thanks! -Ben Before my signature, I'd really like to reiterate that I did not bring up amd64 to open a can of worms. -dho
Re: [9fans] Google finally announces their lightweight OS
2009/7/8 Francisco J Ballesteros n...@lsub.org: ACPI will never, ever, ever happen, so people better get over it (and if anyone is naive enough to waste their time trying, it will end up as a useless atrocious mess that wont boot even in a 100th of the systems out there, much less suspend or do anything useful). I've been wasting time on acpi, and will do waste more time soon. Another person in Plan 9 has been working on an AML interpreter that presents the ADT in a filesystem (at least, that was what I envisioned and explained to him). I believe he has also contacted you regarding some USB ethernet device, so perhaps you two will want to work together to some point? If I can be of any use as well, let me know. I've got a small bit of experience with ACPI (fixing some issues in FreeBSD's acpica support for Intel Blades). ISNT __IT _FUN? sorry, this is just a case convention I've recently seen and I love it. It's certainly fun from a WTF were they thinking perspective. Hardware engineers are rarely amazing programmers. BTW, useless, who knows; but atrocious?, the interpreter is pretty. but what could I say about it? --dho
[9fans] Plan 9 Jobs
In light of Erik's response ``maybe you just don't know about them.'' I looked. http://sfbay.craigslist.org/pen/sof/1243139762.html Recent (posted 6/27). Looks like it's Plan 9 (probably Inferno) on a smartphone. Thought it would be useful to post here in case anybody else is looking for that kind of thing. That said, I couldn't find anything about Coraid openings, so I suspect Erik wasn't tooting his own horn :) I've always thought it would be cool to see what Plan 9-based phones could do on a cellular network. Would be nice to see any / all of these sorts of things appear on this list. We get more people on it every year. I also recall Ron posting some stuff years ago when I was in Holland that I was potentially interested in, however, I don't have a degree and the gov't work he does wouldn't be able to hire me to do anything useful based on my skillset due to their policy. I dunno if Sandia's the same way, but I'd suspect so. --dho
Re: [9fans] Google finally announces their lightweight OS
2009/7/9 Micah Stetson mi...@stetsonnet.org: Why would it take a book? DMR made the point succinctly in his critique of Knuth's literate program, showing how a few command-line utilities do the work of the Don's elaborately constructed tries. Do you have a URL for this? I looked this up yesterday, and there is some discussion on literateprogramming.com -- the discussion actually illustrates how to take the shell script and make *it* literate programming instead. It actually wasn't DMR, it was McIlroy. Micah --dho
Re: [9fans] Plan9 as an everyday OS
2009/7/10 J.R. Mauro jrm8...@gmail.com: On Fri, Jul 10, 2009 at 1:46 PM, j...@csplan9.rit.edu wrote: I'm tired of the perpetual September, after several years of being polite and pointing people to the wiki and the archives. You could filter instead of bitching and contributing to the noise. Spoken like a true hypocrite ;) --dho
Re: [9fans] ide fix?
2009/7/13 erik quanstrom quans...@quanstro.net: after a week of fighting with an atom with ich7r sata in ide mode, i finally found the secret sauce that keeps it from hanging. i pushed out a changed quanstro/9load-e820 and quanstro/sd which boot on my atom machine in ide mode without causing interrupt storms. other changes were included work around ahci power quirks for this chipset, if your bios supports it, i would recommend ahci mode. i also pushed out a version of ether8169 as quanstro/8169 that supports the particular 8169 macs that are in my atom machine (and jumbo frames). i have a feeling that these changes may be helpful in correcting other intel ich-based ide problems. i've got an intel ich6-based machine that has exhibited similar symptoms at work that i hope to test tomorrow. i'll be interested to hear if these changes work for other people. - erik This sounds promising for that ICH laptop with the 320G drive that magically doesn't work (though the 120GB one that was in it was fine). How do I get this on a disc to try it out? --dho
Re: [9fans] ide fix?
2009/7/13 erik quanstrom quans...@quanstro.net: This sounds promising for that ICH laptop with the 320G drive that magically doesn't work (though the 120GB one that was in it was fine). How do I get this on a disc to try it out? can you pxe? Not easily. The issue was a few bits in PCI register space that we weren't entirely sure what they were for but you suspected that they needed to be set up differently for some AHCI power management bits or something like that. --dho - erik
Re: [9fans] v9fs question
I believe Priyanka has some significant work on getting private per-process namespaces in Glendix for this year's GSoC. --dho
Re: [9fans] Plan9 as an everyday OS
2009/7/14 erik quanstrom quans...@quanstro.net: On Tue Jul 14 02:41:02 EDT 2009, sqw...@gmail.com wrote: I suspect the main inhibitor there is that (as I recall) it stomps all over the existing soundblaster code. These days AC97 is probably more desirable, but it would be nice to have them coexist. that's going to require thinking out how ac97 can provide a strict superset of sb. as a first step, it would make sense for ac97 to bring it's own implementation of #A to the party. there are other sound models, it would be nice to design ac97's interface in such a way that it can work with other sound models. Particularly Intel HDA (which supercedes AC97 and is what all new machines are being shipped with now, essentially) and the various chipset codecs on top of that. Plenty of BSDLed code on them and plenty of documentation too. --dho - erik
Re: [9fans] Plan9 as an everyday OS
2009/7/14 Tim Newsham news...@lava.net: However, I still think this is worthwhile just to provide (a) a standard interface for audio devices (e.g., /dev/audioctl always accepts the same messages to set volume, input levels, etc), and (b) to have a single kernel support more than one type of audio device (imagine a network where you actually have an SB16 plus a bunch of AC97 devices and some of these HCI things that Devon mentioned-one 9pc should be able to support them all). I was looking at audio interfaces a little lately and I noticed that inferno's audio device uses different conventions and seems to be more complete. It might be worthwhile to shoot for an interface like that. Several years ago, Kris and I were working on a mixerfs. Neither of us were terribly familiar with digital audio at the time, and it never ended up working entirely properly (read: multiple channels got choppy), but if anybody is interested in the code, I still have it. --dho - Dan C. Tim Newsham http://www.thenewsh.com/~newsham/
Re: [9fans] Why does Acme only show text?
2009/7/15 erik quanstrom quans...@coraid.com: It's a lot easier to see (and not have in the first place) incorrect scope and continuation with whitespace than with braces or parentheses. do you have a reference for this claim? Without turning this into a holy war, I really always see these issues as a matter of personal preference. This is why editors are so bloated and languages have weird conventions. On that note, my personal experience has found it to be a lot easier to find and correct scope issues in Python than it has to find missing braces or semicolons in other languages, sometimes even with matching enabled. This usually is the case for awful spaghetti-ish code. But I digress. --dho
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
2009/7/31 erik quanstrom quans...@coraid.com:
process1:
still in kernel:
memmove(buf, ...)
*fault*
trap()
fault386()
fault() = -1
if(!user){
panic()
*panic*
}
...
postnote()
could you be more specific. what is your test program,
where is it crashing (if you know), and what is the panic
message, if any? i must be dense, but i'm confused by
your process diagram.
He posted it earlier in this thread
--dho
- erik
