Re: [9fans] GCC/G++: some stress testing
On Sat, Mar 1, 2008 at 12:39 AM, Lyndon Nerenberg [EMAIL PROTECTED] wrote: On 2008-Feb-29, at 22:02 , Eric Van Hensbergen wrote: It will no doubt be useful to us folks doing work for the gov't. They DOE has lots of apps written for GCC or Fortran -- while there may be other methods of accommodating these applications, having them just work with GCC (particularly if the GCC fortran could be part of the port) would help us a lot. It could also serve as a baseline for performance/efficiency comparisons with other methodologies such as linuxemu, etc. But none of this code will just work on Plan 9 (especially the Fortran code), so what's the point? We are well aware of the peeling onion effect - it is just a step. Many of the HPC apps will just work with a minimum of fuss, others will require a considerable bit of fuss. To add to Ron's MPQC example, I'll just through out the HPCC benchmark suite: http://icl.cs.utk.edu/hpcc/ -eric
Re: [9fans] GCC/G++: some stress testing
On Sat, Mar 1, 2008 at 9:02 AM, [EMAIL PROTECTED] wrote: Graphics, networking and multithreading are much bigger issues to resolve. So your bittorrent client may be difficult to port and damn easy to redevelop. Any chance you may give it a try? Networking and multithreading are going to be more important than graphics to us -- but as you said earlier, one step at a time. We'll be working towards this stuff as well as part of the FastOS program so hopefully we'll be able to help provide some of these pieces. IBM has already done a good amount w.r.t. supporting POSIX networking APIs using Inferno devip as a backend, I imagine we can apply many of these techniques to APE or other accomodation platforms. -eric
Re: [9fans] GCC/G++: some stress testing
On Fri, Feb 29, 2008 at 10:55 PM, [EMAIL PROTECTED] wrote: Please will anybody who has a Plan 9 objective that can only be attained using GCC/G++ please drop me a line to let me know briefly what it is? If the whole exercise gets a lot of support, I'll happily set up more infrastructure to deal with it (wiki, blog, remote access, whatever Bell Labs would rather not do themselves). It will no doubt be useful to us folks doing work for the gov't. They DOE has lots of apps written for GCC or Fortran -- while there may be other methods of accommodating these applications, having them just work with GCC (particularly if the GCC fortran could be part of the port) would help us a lot. It could also serve as a baseline for performance/efficiency comparisons with other methodologies such as linuxemu, etc. Similarly, I've been working with other folks at potentially using Plan 9 (for instance with the RAMP project) -- they'd be much happier if they knew they could compile apps with GCC. -eric
[9fans] GSOC 2008
(reposting as my initial post bounced because it had too many recipients) (Cross-posted into inferno-list, v9fs-developer, plan9-gsoc, and plan9-gsoc-mentors) Okay, from the deafening silence outside of students and project nominations, it sound like we better get cracking. At the very least folks should start thinking up project ideas and people should decide whether or not they will be available to mentor. For folks unaware of GSoC (aka Google Summer of Code), here's the link: http://code.google.com/soc and also a link to last year's Plan 9 GSoC: http://gsoc.cat-v.org/ I started a toplevel wiki page: http://plan9.bell-labs.com/wiki/plan9/GSoC2008/index.html for people to post interest and ideas -- although I think it would be a good idea to post project ideas in the gsoc mailing list (one message per idea) to make discussion easier -- vetted ideas can then be transfered to the wiki. Its probably also appropriate to start discussing guidelines for project ideas and rules of engagement for how we are going to manage project selection, mentor assignment, and student selections this year as well as discuss volunteers and nominations for project administrators. All of this should probably happen in the plan9-gsoc mailing list (http://groups.google.com/group/plan9-gsoc) to allow folks to opt-in to the noise, so this will be my last cross-post. I'm cc:'ing the inferno list and v9fs-developer list as those projects participated in the Plan 9 GSoC last year (and will likely do so again this year). -eric
Re: [9fans] GSOC 2008
On Wed, Feb 27, 2008 at 4:09 PM, Sape Mullender [EMAIL PROTECTED] wrote: we don't assume students are all 30-years grizzled veterans. I'm not grizzled! we were talking about Gorka.
Re: [9fans] GSOC 2008
key word - Fixed On Wed, Feb 27, 2008 at 4:24 PM, ron minnich [EMAIL PROTECTED] wrote: On Wed, Feb 27, 2008 at 2:10 PM, Eric Van Hensbergen [EMAIL PROTECTED] wrote: we were talking about Gorka. I added at least 20 years to his age when I fixed his Mac. ron
[9fans] GSoC 2008
Perhaps this has all been worked out on some super-secret mailing list or IRC channel - but what's the plan of record for GSoC 2008? We've got till the 12th of March to work something out. -eric
Re: [9fans] Re: DoaC - the beagle has landed
add me if you please. -eric On Thu, Feb 21, 2008 at 1:39 PM, Bruce Ellis [EMAIL PROTECTED] wrote: The restricted group http://groups.google.com/group/dis-on-a-chip has been created. e-mail me if you are interested, or whatever is needed to join. I'm not very familiar with google groups but I guess I'll learn. brucee [end of DoaC pollution of 9fans]
Re: [9fans] An unsuccessful attempt to install on Thinkpad T43
On Feb 19, 2008 12:01 AM, Hongzheng Wang [EMAIL PROTECTED] wrote: Thank you for your reply. I am not familiar with lguest. I browsed the documentation of lguest but cannot grasp the core idea yet. Is it something like vmware? Yes - but much more simple. Ron Minnich has THNX (tiny horrible not xen) which is essentially a USB flash-stick pacakged boot environment for Plan 9 running on top of lguest under Linux with full graphics, network, etc. What you want to do is replicate that without the flash disk and using your underlying Linux (assuming you have or can upgrade to a kernel which has lguest). There was a presentation and paper at the last IWP9 discussing it. Perhaps Ron can point us at the most recent repository of all his stuff. -eric
Re: [9fans] An unsuccessful attempt to install on Thinkpad T43
Since you are already running Linux, you may want to consider lguest - it solves the Ethernet problem and does not incur perceivable performance penalties in the T43. -eric On Mon, 18 Feb 2008 6:55 am, Hongzheng Wang wrote: Hi all, Today, I try to install Plan9 on a Thinkpad T43 laptop. Unforturnately, this attemp failed at last; there are some difficult, at least for me, problems I cannot solve. So I am composing this post to seek help. The cd image I used is Feb 16 built version, downloaded from Plan9's official website. It looks different from a previous version I used to install Plan9 on an old PC. For example, after booting machine with the cd, there are three options (install, livecd, and debug livecd) instead. The first problem I encountered is that DMA could not be enabled during installation, although I have explicitly enable it when I am asked. As a result, the copydisc task is executed so slow. Furthermore, it claims that some files cannot be copied since they don't exist. I try reinstall the system, but it seems that the installation procedure prefer to continuing previous installation. That is, it didn't try to recopy all files from cd and the missing warnings are still there. At last, I ignored them. For boot method, since I have both Linux and XP on my laptop already, I choose grub as multiple boot manager. That is, I select `plan9' as boot method when I am asked and don't install boot instructions into MBR. And configure grub to use `chainloader +1' to boot Plan9. After booting into Plan9, it always stops at `boot from:'. After some investigation, I found the problem is that the installation procedure didn't copy kernel image 9pcf at all without any prompts. This problem is solved by mannually copying /386/9pcf on cd to 9fat partition. But the system often reports certain files are missing. So I decide to reinstall the whole system. I manually delete the Plan9 partition and format fossil. So a fresh installation is eventually executed. Surprisingly, there are no missing files warning again. But when I try to boot it, the computer always reports: PCI System Error on Bus/Device/Function h and crashes, while Linux and XP can still be booted through grub. I don't know why yet :( Another key problem is about the ethernet card. Thinkpad T43 uses Broadcom tg3 card and it seems that this card is not supported by Plan9 yet since Broadcom refuses to open its hardware specification(?). So it becomes so difficult to search for answers and information because I have to switch between Plan9 and Linux. That's all. Thanks. -- HZ
Re: [9fans] ctags on plan 9 with acme-friendly tags
On Feb 17, 2008 1:01 AM, Steve Simon [EMAIL PROTECTED] wrote: there was somthing which analysed C and produced a call graph in the form of input for dot(1) years ago, the problem was a complex program produced a complex graph... I will try to find out the packages name if required, I have a feeling it may have been in comp.sources.(unix misc). Doxygen does this (and data-structure graphs as well) - I'm not sure if its a component which could be easily extracted or not. Actually, I just did this to look at the data-structures and call-graphs for v9fs (http://www.kernel.org/~ericvh/doxygen) -eric
Re: [9fans] Building GCC
On Jan 22, 2008 10:35 AM, ron minnich [EMAIL PROTECTED] wrote: On Jan 22, 2008 4:15 AM, Russ Cox [EMAIL PROTECTED] wrote: why use plan 9 at all? why not just install linux or freebsd? because, like it or not, lack of some familiar apps is a barrier to entry for many, if not most, of the people I show Plan 9 to. That said, I would probably draw the line at KDE ... but not at emacs. Also - some (HPC) apps that we want to run on Plan 9 have silly dependencies on things like X11. However, that gets into a different topic than I think the original poster was talking about. -eric
Re: [9fans] Building GCC
On Jan 22, 2008 11:07 AM, erik quanstrom [EMAIL PROTECTED] wrote: Also - some (HPC) apps that we want to run on Plan 9 have silly dependencies on things like X11. However, that gets into a different topic than I think the original poster was talking about. they're running X on blue gene? that's mad. They aren't. However, some of the apps may want X hooks to compile (even if the GUI aspects of the app aren't used). This is second hand information to me from Ron, so he can probably portray the actual situation better. -eric
Re: [9fans] Easiest way to make a filesystem
On Jan 14, 2008 3:11 AM, Tom Lieber [EMAIL PROTECTED] wrote: Is the easiest way to make a filesystem to make one in C in the way described in Francisco's book? Are there any wrapping libraries for the simplest filesystems? Or filesystems like these to base my work on? Take a look at the man page for p9file(2) - its a starting point for writing simple file systems. I don't think there is something which explicitly helps with stackable/layered file systems -- might be nice if you created one out of your efforts ;) -eric
Re: [9fans] 9P on linux
On Jan 14, 2008 3:56 AM, [EMAIL PROTECTED] wrote:
when I try to connect with it using: ./cl.py glenda localhost
I get 'localhost: Connection refused'
this is my /tmp/u9fs.log:
u9fs
kill 24633
- Tversion tag 65535 msize 16384 version '9P2000'
- Rversion tag 65535 msize 8216 version '9P2000'
- Tauth tag 1 afid 10 uname glenda aname
p9anyauth: afid 10
- Rauth tag 1 qid (0001 0 A)
- Tread tag 1 fid 10 offset 0 count 128
p9anyread: afid 10 state 0
- Rread tag 1 count 12 '7039736b 31406c6f 63616c00'
- Twrite tag 1 fid 10 offset 12 count 12 '7039736b 31206c6f 63616c00'
p9anywrite: afid 10 state 1
- Rwrite tag 1 count 12
- Twrite tag 1 fid 10 offset 24 count 8 '79a74fbb a471ed31'
p9anywrite: afid 10 state 2
- Rwrite tag 1 count 8
- Tread tag 1 fid 10 offset 32 count 141
p9anyread: afid 10 state 3
- Rread tag 1 count 141 '01676c65 6e646100
006c6f63 616c
'
u9fs: couldn't read message
last unix error: No such file or directory
This looks like things are falling down in auth. Why don't you try an
unauthenticated connection first?
[EMAIL PROTECTED]:~/9pfuse# ./9pfuse 'tcp!127.0.0.1!564' /mnt
error: fid unknown or out of range
connect error: fid unknown or out of range
Harder to tell what is going on without any kind of log, but I'm
suspicious its once again some sort of auth problem. You may want to
switch from u9fs to spfs (or one of the other servers).
-eric
[9fans] Internships
IBM Research is starting their internship cycle again. This would primarily be for a summer (late may through august time frame), but I may have a 6 month slot as well. If you are interested send me project ideas, resume/CV, and availability. The longer (6 month)project would be dealing with our Plan 9 Blue Gene work. The shorter project could involve the Blue Gene work or perhaps other Plan 9/Inferno related activities (v9fs, Inferno on FPGA soft core). -eric
Re: [9fans] videos of IWP9 talks
On Dec 12, 2007 11:33 PM, andrey mirtchovski [EMAIL PROTECTED] wrote: also, i'd like to have a word with Mr. Van Hensbergen after class, regarding Bulgarians and font sizes ;) oh, it's all there :P Hey - it was Chuckie that made the original crack. -eric
[9fans] IWP9
My memory is shot. Could the person who had the Plan 9 FPGA interface for the Virtex 4 please drop me a note, and also the person that was interested in trying to finish the GSoC cell port (perhaps the same person, I don't know, last week was a blur). Thanks, -eric
Re: [9fans] Efika PPC?
On Dec 7, 2007 4:15 PM, Geoffrey Avila [EMAIL PROTECTED] wrote: http://www.genesippc.com/efika.php Any idea how tough it would be to get 4e booting on this? Doesn't come with a builtin framebuffer, but seems otherwise well-documented... I'd imagine most of the work would be (as it is for any system we have architecture support for) bootstrap and then perhaps Ethernet. Probably a couple of weeks depending on how obscure their loader is, less if they are using something standard like uboot. -eric
Re: [9fans] plan9 web site down @ 9:35 pm PST
the snow has me hung up in chicago at the moment. only adding an hour and half at this point (knock on wood) -eric On Dec 2, 2007 8:25 AM, Charles Forsyth [EMAIL PROTECTED] wrote: it's probably the snow -- Forwarded message -- From: Lawrence E. Bakst [EMAIL PROTECTED] To: Fans of the OS Plan 9 from Bell Labs 9fans@cse.psu.edu Date: Sat, 1 Dec 2007 21:37:58 -0800 Subject: [9fans] plan9 web site down @ 9:35 pm PST The plan 9 web site apears to be down: http://plan9.bell-labs.com/plan9/
Re: [9fans] IWP9 attendess
On Dec 2, 2007 8:48 PM, Bruce Ellis [EMAIL PROTECTED] wrote: walk up the hill, you lazy bastards. Are you here, I've got your P vs NP book -eric
Re: [9fans] WIP session at IWP9
On Nov 27, 2007 1:22 AM, Anthony Sorace [EMAIL PROTECTED] wrote: I saw that the program draft has been posted (http://plan9.bell-labs.com/iwp9/programme.pdf) - neat! Looks like an interesting lineup. Can someone talk briefly about what the Work-in-Progress session at the end is about? That is, is this content provided by the organizers, or is it more free-form time for attendees? The initial idea was for folks attending to talk about what they were working on without having to prepare a formal paper/30-minute-presentation. I'm not sure what the final format is, but one suggestion was 3-slides/roughly-5-minutes per topic with a short discussion time afterwards -- probably maxing out at 10 minutes. The idea is to be short and pithy, not get into extended design discussions. Perhaps if there is slack time, topics that folks are interested in can be revisited -- either in front of the group or over coffee/beer. (mmm...delicious coffee beer) Individuals can present more than one topic, but we may have to revisit that if there is too much of a time crunch. For example, I've got a few different things I want to touch in on -- v9fs, multi-dimension-file-systems, warren, a Plan 9/Inferno port to RAMP, and maybe some discussion of what's happening with libOS these days (we'll already be covering the blue gene update in our talk). Of course, given that that's almost 30 minutes worth of topics, I may have to selectively trim a bit ;) Ideally, folks will have their slides prepped ahead of time and in PDF so we can just dump them all on a laptop so we don't have to deal with 5 minutes of setup time per person. -eric
Re: [9fans] WIP session at IWP9
there was a camera in the classroom, I suppose if all else fails I can capture with a webcam Will probably suck for sound though. I have a video camera, but I need to see if my directional mic works... -eric On Nov 27, 2007 4:05 PM, andrey mirtchovski [EMAIL PROTECTED] wrote: better yet: videos. i will gladly handle the reencoding and hosting for russ' tutorials if someone videotapes them. On Nov 27, 2007, at 12:51 PM, Pietro Gagliardi wrote: I'm not coming to IWP9 this year, but I looked at the transcript and I was interested in some of them (Acid Trips - does it discuss using the program? I'd love that...). I was wondering if transcripts of the talks would be available after that.
Re: [9fans] From our not quite grasping the concept file
On Nov 8, 2007 6:00 AM, Richard Miller [EMAIL PROTECTED] wrote: So, the decision in the linux virtualization world is to make all paravirtual devices look like ... drum roll ... PCI devices. That's really tragic. Virtualisation of devices would be such a good opportunity to invent a nice simple interface abstracting away from all the hardware constraints. Sure, all the guest OSs will need new drivers - but using a simple interface means they should be really easy to write. The opportunity still exists -- only one driver needs to implement their numeric hack - 9p. Then the rest can be based off of that. Unfortunately, evolution just comes slow and painful. -eric
Re: [9fans] From our not quite grasping the concept file
On Nov 8, 2007 9:20 AM, erik quanstrom [EMAIL PROTECTED] wrote: The opportunity still exists -- only one driver needs to implement their numeric hack - 9p. Then the rest can be based off of that. Unfortunately, evolution just comes slow and painful. -eric are 9p mesages really the right vehicle for this? 9p messages provides a serialized and in a standard byte order. this requires byte reordering (on intel) and copying. but are these really needed? the guest and host are on the same platform, so the guest can pass pointers to the host. for the same reason, integers don't need reformatting. 9p is the right organizational structure. The details of marshalling and pass-by-copy versus pass-by-reference are transport issues. Lucho and I have been playing with zero-marhsalling/zero-copy transport variants of 9P for virtualized environments. -eric
[9fans] consterm
Has anyone done a term program to connect to Plan 9 or Inferno -- kinda like drawterm, without the draw bits? I guess I am thinking about something that exports /dev/cons, /mnt/term, /dev/audio, etc. -- but then just runs an rc on the other end instead of rio so I can just run it within an xterm (or whatever). Seems like it would be a useful thing to have. -eric
Re: [9fans] The utility of a chording pad
On 8/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So I've spent a lot of time today watching recordings of Engelbart's 1968 demonstration (http://sloan.stanford.edu/mousesite/1968Demo.html), and I really like the chording pad he has over on the left of his keyboard. It's the same type of thing that shows up again in the Xerox Alto. I'm just wondering, as Plan 9 users and developers, what would you do with such a thing in the environment? Engelbart's device apparently let you input 31 different chords, which I'd say isn't sufficient to replace a keyboard but is still pretty impressive; with such a thing, would you perhaps bind the chords to perform acme commands, for instance? We've already got mouse chording, and it's pretty slick; add some more chording in, say hit the first two keys in order to delete the current frame in acme. Of course, if we were to get a chord pad that could produce enough combinations for all alphanumeric characters, it could be used to replace the keyboard. I'd just like to get some opinions, see what you think of chording devices and what potential utility they could have in Plan 9. I always thought it'd be cool to hack up something for http://catalog.belkin.com/IWCatProductPage.process?Product_Id=157024 to do left handed chording and keep the right hand on the mouse. I bought one and played around a bit, but was unsatisfied with my ability to actually detect chords without writing a proper driver IIRC. I experimented a bunch with different chording setups a decade ago and found most unsatisfactory, but half-keyboard chordic setups seem to be quite easy to pick up - the problem with the Nostromo was that it was like 2 keys short of being a proper half keyboard so you needed more than one meta-key ... which was offputting. Plus no numbers made it kinda hard to code with. -eric
Re: [9fans] consterm
On 11/6/07, Uriel [EMAIL PROTECTED] wrote: Why not just use Inferno? Caerwyn posted two lines that can be run on an inferno terminal and will 'cpu' into a plan9 box. I'm looking for something lighter weight than Inferno or full-blown Drawterm -- something that lets me 'cpu' from an xterm is just about right -- and I can accept using a 'consterm' version of drawterm to get that light-weight access. Part of this is personal laziness -- I usually need to get in and out to copy files, which I could do if I just used a proper v9fs setup plus factotum. I actually wanted one of these for Inferno as well - we were using a single Inferno instance to manage multiple libOS partitions - it seemed kind of silly to start up other Inferno partitions just to launch applications on the controller Inferno. I ended up working around this in another way, but something like cpu would have been preferable. However, I'm also thinking longer term - towards the FastOS project where users aren't going to necessarily want to fire up a whole 'environment' such as Inferno or Drawterm just to execute an application on the cluster -- particularly if that application isn't graphical. -eric
Re: [9fans] consterm
On 11/6/07, Russ Cox [EMAIL PROTECTED] wrote: On 11/6/07, Eric Van Hensbergen [EMAIL PROTECTED] wrote: Has anyone done a term program to connect to Plan 9 or Inferno -- kinda like drawterm, without the draw bits? I guess I am thinking about something that exports /dev/cons, /mnt/term, /dev/audio, etc. -- but then just runs an rc on the other end instead of rio so I can just run it within an xterm (or whatever). Seems like it would be a useful thing to have. It is trivial to rip the gui out of drawterm and make reads and writes to /dev/cons redirect to reads and writes on /dev/tty instead of the graphics console. Patch below. There is no p9p cpu, only the very very sketchy beginnings. You're much better off starting with drawterm, especially if you want things like /dev/audio. Cool - kinda figured it would be easy to mod drawterm, just wondering if someone had already done it. Thanks Russ. -eric
Re: [9fans] consterm
On Nov 6, 2007 5:35 PM, erik quanstrom [EMAIL PROTECTED] wrote: However, I'm also thinking longer term - towards the FastOS project where users aren't going to necessarily want to fire up a whole 'environment' such as Inferno or Drawterm just to execute an application on the cluster -- particularly if that application isn't graphical. i think i don't understand your problem, as drawterm runs on the host, not the client. if you had one cpuserver, you could cpu into the target nodes without starting very much on them. why won't that work? Its more of a perceived weight rather than an actual weight (perhaps that's bogus, but we are trying to win hearts as well as minds - so keeping things for end-users as familiar as possible is desirable). We want to maintain the appearance of things being transparent (like with cpu) -- not have a framebuffer automagically pop up. Having back access to files and environment is something we want to maintain (along with auth) so telnet isn't really an option. jmk points out there are other issues with this approach, but I feel confident we can create a tighter coupling between legacy systems and Plan 9/Inferno. -eric
Re: device-specific qid.version behaviour (was Re: [9fans] QTCTL?)
On 11/5/07, Skip Tavakkolian [EMAIL PROTECTED] wrote: maybe 9p2010 Tread/Twrite could include the qid, which may be supplied by the client (or left out). if qid is supplied then the fs has the option to enforce it; otherwise it works as it does now. Confused as to what you are saying here - could you clarify? -eric
Re: [9fans] QTCTL?
On 11/1/07, roger peppe [EMAIL PROTECTED] wrote: i don't really want to teach this filesystem about which files are conventionally normal - and it would be nice to just run one instance for an entire exported fs (accessed through another name, as brian stuart's example). Yes - I think transitive mounts, the desire to be able to mount pre-composed file systems, and even mixed mode synthetics (which have both ctl files and cacheable data) all lean toward having a way of identifying what should be cache-able. For instance, my Libra libraryOS environment currently only has a single channel with which to mount all resources -- so it mounts the file system at the same time as console and network files. I imagine if we ran 9p directly on top of one of the raw interconnect channels on Blue Gene we might be in a similar situation (although we aren't currently looking at that). -eric
Re: [9fans] QTCTL?
On 11/1/07, Russ Cox [EMAIL PROTECTED] wrote: One could, of course, use a different protocol with a 9P front end. That's okay for clients, but you'd still have to teach the back-end server (i.e. fossil) to speak the other protocol directly in order to get any guarantees. (If 9P doesn't cut it then anything that's just in front of (not in place of) a 9P server can't solve the problem.) Sorry, could you clarify what you mean by this? -eric
Re: [9fans] QTCTL?
On 11/1/07, Francisco J Ballesteros [EMAIL PROTECTED] wrote: We did look at nfs v3 and lbfs before implementing op. nfs v3 at least tried to address latency and not just bandwidth as lbfs, but it seemed to use more RPCs than needed for some tasks (I don´t remember now, but have that written down somewhere). IIRC, NFSv4 has more lease negotiation stuff as well as compound operations. Of course its like a 500 page spec and looks to be more of an example of what not to do IMHO... -eric
Re: [9fans] QTCTL?
On 10/31/07, Francisco J Ballesteros [EMAIL PROTECTED] wrote: while hunting yet another bug in the octopus, I´ve been thinking that one problem that we have in general, in Plan 9, is that there are files that behave like files, and files that do not. For example, append only files do not, offsets are ignored on writes. ctl files are not, either. You write a ctl string, and reading the file reports something else. Clone files are different files, each time they are open. This is a problem when (like we do in the octopus) you try to cache files. But it´s also a problem for things like tar and to whoever tries to use the file as a plain one. Why don´t add a QTCTL bit to Qid.type? It would mean this file does not behave like a regular file, do not cache and handle with care). IIRC, qid.version == 0 is used to mark synthetics (like ctl) for the purposes of being marked as uncacheable and should be handled with care. -eric
Re: [9fans] QTCTL?
On 10/31/07, Charles Forsyth [EMAIL PROTECTED] wrote: IIRC, qid.version == 0 is used to mark synthetics (like ctl) for the purposes of being marked as uncacheable and should be handled with care. i don't see that anywhere. MCACHE allows things in a mounted space to be cached; otherwise, i'd suppose not. hurumph. Don't know where i got that from - I tried to base my v9fs cacheing stuff on cfs.c, but I don't see any qid.version==0 checks there. Then I thought perhaps it was from a conversation wtih Russ when I was doing cacheing in v9fs -- but on searching my gmail he was saying that it didn't always hold true -- so perhaps something new is needed... -eric
Re: [9fans] QTCTL?
On 10/31/07, erik quanstrom [EMAIL PROTECTED] wrote: Why don´t add a QTCTL bit to Qid.type? It would mean this file does not behave like a regular file, do not cache and handle with care). why are the current namespace conventions insufficient? /mnt, /net, and /dev hold most, if not all, of the special files. The dynamic nature of namespace works against such conventions. Besides it would be nice to have a mechanism that could work in other systems that use 9p. File servers should be able to convey whether a file is cache-able or not. -eric
Re: [9fans] QTCTL?
On 10/31/07, Charles Forsyth [EMAIL PROTECTED] wrote: QTCL would ... perhaps one of my points is that in the Plan 9/Inferno world, you'd be better off marking the files you can cache, not trying to identify the ones that you can't. one reason is the practical one of having to touch perhaps two or maybe three important servers instead of everything. That makes a lot of sense -- particularly in a Plan 9 context. It should be straightforward enough to modify appropriate static content file servers to set this bit. The current range of non-Plan9 servers (u9fs,spfs,etc.) present a bit of difficulty in that there isn't a good way to transitively detect this sort of thing when say a p9p server is mounted on Linux and then re-exported, mapping it through the Linux VFS space. But then I suppose that's just a matter of not using the aforementioned tools to export special files or file systems. I've got some ideas to fix this that I want to play with using Lucho's new in-Linux-kernel-9p-server. Of course, all of this is probably a corner case that most people don't see anyways. In the context of FastOS, dealing with thousands of nodes, we are going to need to implement more sophisticated forms of caching. Since this is going to be pretty critical to even booting at larger scale, its likely we'll be digging into this early next year. We'll keep folks in the loop as we get prototypes working. -eric
Re: [9fans] QTCTL?
On 10/31/07, erik quanstrom [EMAIL PROTECTED] wrote: If the file is decent, the cache must still check out that the file is up to date. It might not do so all the times (as we do, to trade for performance, as you say). That means that the cache would get further file data as soon as it sees a new qid.vers for the file. And tail -f would still work. the problem is that no files are decent as long as concurrent access is allowed. control files have the decency at least to behave the same way all the time. Sure - however, there is a case for loose caches as well. For example, lots of remote file data is essentially read-only, or at the very worst its updated very infrequently. Brucee had sessionfs, which although more specialized (I'm going to oversimplify here Brzr, so don't shoot me), could essentially be thought of as serving a snapshot of the system. You could cache to your hearts content because you'd always be reading from the same snapshot. If you ever wanted to roll the snapshot forward, you could blow away the cache -- or for optimum safety, restart the entire node. With such a mechanism you could even keep the cache around on disk for long periods of time (as long as the session was still exported by the file server). -eric
Re: [9fans] QTCTL?
On Wed, 31 Oct 2007 8:44 pm, erik quanstrom wrote: Sure - however, there is a case for loose caches as well. For example, lots of remote file data is essentially read-only, or at the very worst its updated very infrequently. Brucee had i might be speaking out of school. but i worry about the qualifiers essentially and very infrequently. they tend not to scale. what about drawing a sharp line? these mounts are static and cachable. these are not and need coherency. Yes - sessionfs satisfied the first case, items falling into the second class were served from a normal 9p server (w/no cache). perhaps the data that needs cache coherency doesn't need full file sematics. I think they are two separate issues. -eric
Re: [9fans] Authenticated mounts from non-plan9 systems
On 10/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi eveyone! I've been a fan of plan9 for quite a while, using it whenever I had a machine that would run it. Now I have a small network of machines at home, with one plan9 auth+cpu+fs server (yeah, I know that's not much, but I don't have any more hardware that would run it). I'd like to be able to mount the exports on that machine to other machines (mostly linux): I've been able to get a non-authenticated mount via p9p, but I can't seem to be able to get an authenticated mount. srv says there is no authentication needed. I was wondering if this was a p9p limitation or wether my cpu+auth+fs server was missing something, or if I was doing something wrong. Here is how I am mounting it right now: $ srv -a sorosj.hd.free.fr rx: exportfs: authentication not required so there is no authentication, though I can do $ 9 mount `namespace`/sorosj.hd.free.fr /tmp/tmp and then I can see my root, but I can't write to it. This is regardless of wether I supply mount with authentication parameters or not (eg. -o user=$USER,,proto=UNIX ) Any help would be greatly appreaciated. If this is using v9fs under the hood, I believe you'll need to supply uid/gid parameters as well as authentication. Non-9p2000.u mounts (ie. mounting p9p apps or plan9) don't have uid mapping. Otherwise turn on debug (-o debug=0xff) and send a trace to v9fs-developer and we'll see if can figure out what is going on. -eric
Re: [9fans] Plan9ports under windows/cygwin?
On 10/25/07, Paul Lalonde [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It works fine as an editor, but if I understand correctly runs command lines under the hosted Inferno; is there some way I can set it up to run windows command line tools? I need to run my compiler... The os(1) command will do that for you. Maybe it would be slick if acme optionally just ran every middle click through the os(1) command. Of course, terminal windows might need a bit more complexity - but those are for sissies (like me) anyways. -eric
Re: [9fans] blit, gnot, and portrait monitors
On 10/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Reading about those terminals made me want (again) to use a portrait layout with my Plan 9 box. If I took a regular monitor and laid it on its side, are there options that would allow me to display on it correctly (rotated 90 degrees)? Would I have to hack around on my own? Thanks hosted things (like Inferno and drawterm) will just work. For native, you'll have to do something on your own -- but stuff the high-level graphics stuff is straightforward so its actually a nice little project. Just give us a name space interface to set the rotation.
Re: [9fans] parallel/distributed computation
On 10/17/07, ron minnich [EMAIL PROTECTED] wrote: You have two choices. 1) write it from scratch 2) port gcc and then all of gnubin -- and then all of the various parallel computing software Ron fails to mention that we are also looking at flushing out support for large-scale HPC applications under Plan 9 -- but that work is just getting underway and Fortran isn't one of our initial targets (although some level of MPI API support most likely is). -eric
Re: [9fans] Re: what about microkernel?
On 10/8/07, erik quanstrom [EMAIL PROTECTED] wrote: His original Kernel, L3, was written in pure assembly for x86, using every trick possible. there's nothing wrong with assembly per ce, but i don't follow this logic. generally speaking, compilers are better than humans at doing instruction scrabble. Depends on the compiler ;) Ignoring the C++ (or all-assembly) nonsense, the general point of L3/L4 seemed to be do IPC really, really well on whatever platform we are running on and then build a microkernel around it. That's an oversimplification, and perhaps at that level of abstraction -- that was the goal of every microkernel (its just many/any didn't succeed at that goal). I've been thinking a lot about this, particularly as we've been diving deep into tracing performance of our network paths as part of the Blue Gene work. As of our preliminary results, it would seem that Plan 9 attempts to take the most general approach to things with an emphasis on keeping everything simple. Unfortunately we end up paying a heavy price in raw performance (at least in the networking case). It may well be that benchmark performance is irrelevant, but I think its at least worth reviewing other-OS research from the last 20 years to see what we can learn. It may be the case that we have cut our abstractions too high to take advantage of some architectural features present in modern microprocessors -- it may be that we want to allow for optimized locking and IPC/queues on particular architectures. I've heard mention the idea of turning the Plan 9 kernel into a a pure 9p mux and building the system around that -- one wonders how different we would look from a microkernel environment like L4 then. I know the Japanese folks talked about their efforts of porting Plan 9 on top of L4 at last years IWP9 -- I wonder if they've made any further progress... -eric
Re: [9fans] Re: what about microkernel?
On 10/8/07, Charles Forsyth [EMAIL PROTECTED] wrote: It may be the case that we have cut our abstractions too high to take advantage of some architectural features present in modern microprocessors -- it may be that we want to allow I might draw a different conclusion. As with some peculiar memory subsystems, botched device interfaces, or 80 core processors, I'd say that perhaps the architectural features are there to meet the needs of hardware designers and are not actually designed to run the programs people are actually writing. Perhaps someone told them the software people wanted some of this stuff, but I've got my doubts! I would be tempted to draw the same conclusion if other implementations didn't seem to do a better job. Granted, our existing points of comparison are highly specialized, but I still believe we can accommodate both specialized and generalized cases as well as find middle ground which may make the most sense for applications. Further, I wonder if some of our locking interfaces may be better built using some of the experiences of the past 20 years -- in particular for larger SMP. Also, I wonder if we have the right set of abstractions for our locking and queueing primitives for all architectures. In particular -- if massive multi-core architectures evolve to support IPC more natively, we'll want to take advantage of those primitives. Another examples is whether or not we could make better use of the reservation based schemes on modern PPC versus the TAS model. It just seems like given the architectural differences between the various platforms we support, we might be able to do better native versions of higher level primitives rather than just providing uniform support for lower level primitives and always basing the higher level primitives on that. Perhaps someone told them the software people wanted some of this stuff, but I've got my doubts! Well, we can put ourselves in the position of requesting that stuff. Designs for next generation Blue Genes and Power processors are still in flux. One of the downsides of focusing on the available generation is that we are losing out on the ability to try and affect the next generation(s). -eric
Re: [9fans] Re: what about microkernel?
On 10/8/07, erik quanstrom [EMAIL PROTECTED] wrote: I've been thinking a lot about this, particularly as we've been diving deep into tracing performance of our network paths as part of the Blue Gene work. As of our preliminary results, it would seem that Plan 9 attempts to take the most general approach to things with an emphasis on keeping everything simple. Unfortunately we end up paying a heavy price in raw performance (at least in the networking case). i have found plan 9 ip networking does not fair well pushing ip networking at 10gbps, especially tcp, and especially with standard ethernet frames. i didn't spend enough time this spring with the tcp stack to understand what it's doing, but i got the impression that it could make the simple case of receiving packets in order simplier at the expence of misorderd packets. fwiw, we get much greater performance pushing AoE. so i don't think that network queues themselves are the problem. I think most of the issues we are facing are due to somewhat difficult esoteric network interfaces combined with a single 700 MHz simple embedded in-order processor. That being said however, any advantages we can get on the relatively slow hardware should benefit the efficiency (if not the latency and performance) of the faster platforms. Even if we can push peak on our platform it won't help us if we are chewing up cpu cycles that we need for computation. -eric
Re: [9fans] Re: what about microkernel?
On 10/8/07, Charles Forsyth [EMAIL PROTECTED] wrote: That being said however, any advantages we can get on the relatively slow hardware should benefit the efficiency (if not the latency and performance) of the faster i think there's quite a bit of scope for performance improvements without doing violence to the overall structure or messing up the implementation. i hope some things end up being smaller and cleaner. Agreed. Performance does not necessarily equal complexity. Neither does allowing specialization -- I think specialization enables simplification and clarity in many situations. -eric
Re: [9fans] plan9.bell-labs.com
hate to pay that bandwidth bill On 9/21/07, David Leimbach [EMAIL PROTECTED] wrote: On 9/20/07, Richard Bilson [EMAIL PROTECTED] wrote: On 9/20/07, David Leimbach [EMAIL PROTECTED] wrote: And I just had a really evil idea involving Amazon's S3 storage service... I think we may have had the same idea. And I have code, too. Venti arenas stored on S3, with locally hosted indexes?
Re: [9fans] Server management
On 9/13/07, Enrico Weigelt [EMAIL PROTECTED] wrote: while thinking about my plans for using 9P servers in numerious situations I just realized that server management can become quite complex. For example if an application like mozilla would move out many jobs (ie. like currently discussing @ mozilla.org: rss-feeds), server management can be quite complicated. We can't expect neither the user nor the individual application to be responsible for that. We need some zero-configuration approach. Actually it can be done by another server, which knows about all the individual servers, handles startup/shutdown and tells the clients where to find them, how to authenticate, etc, etc. A little bit like RPC portmap. What do you think about this idea ? While going with something standard (but a bit sticky) like zeroconf may be attractive, you may want to look at what the Plan B guys did -- IIRC they have network discovery and organization integrated into their basic framework. Essentially I think it makes the most sense to work this sort of auto-discovery into existing services (ndb/cs for instance). Accomodating zeroconf as a protocol would be nice (particularly from a cross-platform compatibility angle), but you could also do something like Inferno's registry. -eric
Re: [9fans] 1/2 OT: per-process mounts/namespace @ Linux
Linux actually has private namespaces, its just off by default. There is a flag to clone which can be used to establish new processes in private namespaces (CLONENS or some such thng). Primary downside is that its superuser only -- but you could get around it with setuid or custom kernel. -eric On 9/7/07, Enrico Weigelt [EMAIL PROTECTED] wrote: Hi folks, I was just reading some older mails on this list and thinking about how to mimic the plan9 behaviour of local namespaces on Linux. My idea is: * each namespace is just some directory, ie. living somewhere under /.NAMESPACES/, maybe /.NAMESPACES/pid/ * these namespaces are maintained by either some daemon or an special synthetic filesystem * processes with private namespaces are chroot()'ed to their own namespace directory. What do you think about this ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] 1/2 OT: per-process mounts/namespace @ Linux
There has been extensive discussion of multiple options here -- the least of which is the paper I presented at OLS a few years back (Glen or Glenda: http://citeseer.ist.psu.edu/vanhensbergen05glen.html). There's an approachable list of safeguards. Of course, if its your desktop, you probably don't care to implement any of them... -eric On 9/7/07, Latchesar Ionkov [EMAIL PROTECTED] wrote: The simple solution would be to disable setuid/setgid flags for private namespaces of users other than root. And then (not so simple) fix programs that don't work :) Lucho On 9/7/07, David Leimbach [EMAIL PROTECTED] wrote: On 9/7/07, Eric Van Hensbergen [EMAIL PROTECTED] wrote: Linux actually has private namespaces, its just off by default. There is a flag to clone which can be used to establish new processes in private namespaces (CLONENS or some such thng). Primary downside is that its superuser only -- but you could get around it with setuid or custom kernel. -eric Then you have to worry about what happens when people do things like binding over /etc/passwd :-)
Re: [9fans] plan 9 overcommits memory?
I was thinking that this was probably what we wanted to do for HPC also, having the option of turning off zero-filling pages -eric On 9/3/07, ron minnich [EMAIL PROTECTED] wrote: One option for Erik: try changing the segment allocator so that it faults in all segment pages on creation. Would this do what you want? I will try this if I get time later today. Assuming it is as simple as my simple-minded description makes it sound. If it would, maybe a simple echo faultall /proc/pid/ctl would be useful would be interesting: iterate over all segments, and make sure each has a real page for all pages in all segments. I can see the need for not overcommitting, and also for actually creating and filling out the pages on malloc or other allocation. Indeed, lack of OS thrashing due to paging is one feature cited by proponents of this: http://www.cs.sandia.gov/~smkelly/SAND2006-2561C-CUG2006-CatamountDualCore.pdf ron
Re: [9fans] farewell to /sys/src/fs and IL
On 8/31/07, Skip Tavakkolian [EMAIL PROTECTED] wrote: thanks for pointing this out. it would make things more difficult here. anyone have any notes on migrating from kenfs to fossil/venti? in a semi-related question, is their a published procedure for migrating to nventi, or is it painless? -eric
Re: [9fans] Fortran?
On 8/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Does Plan 9 support any sort of Fotran programming? Thanks for the help. Beyond f2c, there was the cursed gcc port which one could probably get g77 out of... Legacy HPC application accomodation is on the agenda of the department of energy proposal we submitted . If its accepted, coming up with a more complete story on Plan 9 Fortran support will no doubt be on the agenda... -eric
[9fans] Plan 9 Overview Slides
Found this while googling for something else: http://www.scs.stanford.edu/07wi-cs244b/notes/l13d.txt
Re: [9fans] 9P vs. FUSE
On 8/10/07, Latchesar Ionkov [EMAIL PROTECTED] wrote: It is not that hard to create few setuid helper programs that make Linux support Plan9-like private namespaces. The union mount would be tricky, is unionfs accepted in the standard kernel yet? Its in -mm, and now there is the secondary union directory (more like Plan 9 mounts) that is going in as well. -eric
Re: [9fans] 9P vs. FUSE
On 8/10/07, Uriel [EMAIL PROTECTED] wrote: Strange, this is not what I remember from IWP9 at all. What I remember is that pretty much all requirements people had could be accommodated *without* changing the existing 9p2000 protocol by using conventions on special attach names to provide access to extra required functionality or other such tricks (the exception was the idea of how to group messages, which unfortunately nemo seems to have discarded but I still think is so far the only real improvement 9p might need, and it could be largely backwards compatible) (Sigh) IIRC there were several proposed extensions such as caching, security, (and perhaps extended attributes) that could be done under alternate aname semantics. However, for more complicated experiments (such as the message groupings) would use new operations which could be easily filtered out by servers which didn't support them instead of the mess we have with .u and different operands for existing operations. Of course, my memory could be wrong, but it would be really sad to see yet another 9p variant pop up after the .u debacle when I think the consensus was clear that 9p could handle just fine pretty much everything everyone wanted (again with the exception of the message grouping for high latency links). In any case, it would be nice if people considering changes to the protocol could be a bit more open about it so we could have some discussion about how much sense it makes, and we could avoid a repeat of the waste of time and effort with .u. Yes - you are right, its much better to work things out in committee versus actually write some code to figure out how things work out in practice. That's just the way its always been done in Plan 9. And so many people had so much time wasted in the .u effort -- all those hundreds of programmers working thousands of hours on adding .u support, all for nothing. Oh, wait -- there was only one other programmer working on this stuff besides me, sorry lucho. Vote with your code, otherwise please keep to your elite development lists. -eric
Re: [9fans] 9P vs. FUSE
On 8/10/07, Latchesar Ionkov [EMAIL PROTECTED] wrote: It is not only matter to forward-port it, but also get it accepted into the kernel. I have to check what is the other union mount that Eric mentioned. http://lkml.org/lkml/2007/7/30/193 On a somewhat related topic, we'll probably want to enable some sort of simple copy-on-write mode for paravirtualized file-system 9p servers -- it strikes me that it might be better done in a single server (cow semantics+whiteout along with UNIX file gateway service). -eric
Re: [9fans] 9P vs. FUSE
On 8/10/07, Enrico Weigelt [EMAIL PROTECTED] wrote: * Skip Tavakkolian [EMAIL PROTECTED] wrote: did anyone do any comparisons on 9P vs. FUSE for (mostly-)local uses ? fuse is a clever hack for doing user space fs in unix. look at russ' 9pfuse in p9p. Okay, that's an FUSE-based 9p client. What about FUSE-based 9p servers ? I don't think FUSE-based 9p servers makes any sense. Over simplifying, FUSE provides a user space API into the UNIX VFS layer -- 9p provides an API and Protocol into Plan 9's file server interface (which may be local kernel, local user, or across the network). Plan 9's file server interface is an elegant (and small) approach, UNIX VFS is a much larger, more complicated (and many would argue more complicated and larger than necessary) interface. Plan 9's interface is well suited to Plan 9. UNIX's interface is well suited to UNIX. Now, that being said, we have 9p under UNIX (both in p9p and v9fs, and many other incantations), and it seems to work just fine for many things. We took a stab at extending 9p to match some of the UNIX semantics (links, special files, etc.) and it was called 9p2000.u and is implemented in the v9fs client and the spfs server code (there is an RFC if you google for it). However, it was decided at the last IWP9 that we had probably taken the wrong approach with 9p2000.u and it would probably have been better to extend 9p with new operations that had different syntax/semantics from standard 9p as these would be easier to filter out. I'm currently playing with a new design in my copious spare time. It was further suggested by some that a better approach on Linux/UNIX would have been to take what we know from 9p and design a protocol specific to the VFS (similar to FUSE but capable of transparent network, etc.) Some of the recent v9fs effort has been looking at 9p for paravirtualized file system access between hosts using shared memory transports. Much initial work has been done using 9p and 9p2000.u, but requests for more comprehensive solutions have been requested by customers/interested-parties with full support for Linux capabilities. As such, there may be a foray into providing something along the lines of a new set of extensions supporting all Linux VFS operations (perhaps I'll call it 9p2000.l) However, such support is mainly necessary for folks looking to remote access feature rich on-disk file-systems. I believe straight 9p is more than adequate for 99% of synthetic file systems with something as simple as 9p2000.u giving you extra bits necessary for basic UNIX compatibility. -eric
[9fans] devip connect error state
So -- in devip on Inferno hosted we have this bit of code: (connectctlmsg)
if(c-state != Idle)
error(Econinuse);
c-state = Connecting;
...
if(waserror()){
qlock(c-l);
c-state = Connected; /* sic */
nexterror();
}
/* p = x-connect(c, cb-f, cb-nf); */
so_connect(c-sfd, ip6w(c-raddr), c-rport);
qlock(c-l);
poperror();
In native inferno (and Plan 9) devip we have this bit of code:
if(c-state != 0)
error(Econinuse);
c-state = Connecting;
...
if(waserror()){
qlock(c);
nexterror();
}
sleep(c-cr, connected, c);
qlock(c);
poperror();
--
The result being if the connect fails, the state remains Connecting,
and subsequent writes of 'connect' commands fail because Econinuse.
In Plan 9/Inferno, this doesn't really matter much because if dial(2)
fails we close the fd to the ctl file.
Now in the Libra library OS stuff that I've been working on, we are
using a slight different (more socket-ish) semantic. There's nothing
in the devip man pages that say that I can't issue new commands to the
ctl file after a failed command.
So, bug or feature? At the very least it would seem a good idea to
set c-state to Hungup (and also change the c-state != 0 to a
c-state != Idle). I have no idea why we set c-state to Connected in
Inferno hosted -- that just seems completely bonkers.
-eric
Re: [9fans] Bay Area Plan 9 Users Group Meeting (August '07)
On 8/8/07, ron minnich [EMAIL PROTECTED] wrote: On 8/8/07, Charles Forsyth [EMAIL PROTECTED] wrote: Fix is to give it lots of dma segments so that you can stay ahead of the traffic. but is that then guaranteed, or just a matter of luck? That's a great question. I believe it is a matter of luck. But if you get the interrupt, and you put the new pointers in the dma struct quickly, and it has not wrapped around, well, you're in luck! ron p.s. Actually, it does not matter, lguest is going to replace its I/O with the paravirt IO standard ops in the next release. That really doesn't seem right, I looked more at the block and the console code, but it seems like there should be code which claims posted DMA buffers and then the guest should have to re-post them. I have three different designs for the 9p transport on lguest. I think I shall do them all just so I can add a choose your own adventure style to Rusty's documentation. a) follow the console driver style and just shuffle to named/pipe socket to 9p server b) follow the libos style and just use a shared memory buffer posted in dev-mem that is mmaped from shared memory with the server c) use dev-mem to store fcall slots and use the dma buffers to shuffle payload -- this should be the optimal zero-copy case (a) can theoretically target any 9p server, (b) will work against inferno-tx and (c) will work against a modified spfs and will take some pretty heavy modifications to v9fs (don't need to marshall the fcall, just stick it in a struct in shared memory). The idea is to compare the performance of the three approaches and see just how much cost (performance and complexity) is involved in each. Should have (a) done in a matter of hours. -eric
Re: [9fans] devip connect error state
On 8/8/07, Charles Forsyth [EMAIL PROTECTED] wrote: c-state != Idle). I have no idea why we set c-state to Connected in Inferno hosted -- that just seems completely bonkers. the /* sic */ tells you that yes, it looks odd, but it's meant that way. I kinda figured, but I was still left wondering why? -eric
Re: [9fans] Plan B instructions
Why not add it to the wiki? -eric On 8/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm pretty sure I haven't mentioned this yet, so... people interested in playing with Plan B, I have put together a short text document describing how I got to a reasonably-working state under qemu. It was of course written *after* I finished setting everything up, so it could have some errors. Anyway, the file can be fetched from: http://csplan9.rit.edu/users/john/planb.txt Your mileage may vary... please don't come to me because you screwed up your fancy cpu/auth/file server setup trying to install Plan B! Good luck! John
Re: [9fans] What do I need for a small 9P2000 server @ Linux ?
On 6/28/07, Uriel [EMAIL PROTECTED] wrote: See http://9p.cat-v.org I'm still waiting for some kind of npfs/spfs release I can link to from there, last I checked spfs was only accessible as some random tree in the v9fs cvs. I put a tarball out at sf.net (npfs project). -eric
Re: [9fans] What do I need for a small 9P2000 server @ Linux ?
On 6/28/07, Enrico Weigelt [EMAIL PROTECTED] wrote: The 9p driver in linux-2.6.19 (which currently is the latest stable in Gentoo) is some bit broken. First I had to fix the init function to abort if the result code if the called functions (ie. register_filesystem) is non-zero instead of zero ;o And if you're mounting the npfs or u9fs server and chdir into the mountpoint's subdir under the mountpoint itself, the process will hang (forever?). Obviously an recursion problem. yeah - bad luck on that kernel -- I was a crappy maintainer and wasn't doing proper regressions and some runtime bugs slipped in without me seeing it. You should be able to backport the fs/9p code from the latest and greatest official kernel (not the v9fs devel directory) without much trouble and things will be much more stable for you. The recursive mount problem is something that you have to watch yourself on -- single threaded file servers (like spfs and u9fs) will just end up blocking indefinitely. There are cases where you can screw with multithreaded file servers and blow your kernel stack recursing. When it comes down to it, it is a misconfiguration, you shouldn't loopback mount stuff in such a way that you recurse -- one way around it is to always mount in a new namespace (which is what Plan 9 does). Without private name spaces there are no good solutions which we could work out. -eric
Re: [9fans] What do I need for a small 9P2000 server @ Linux ?
Uriel maintains a web page with all the different options for various languages. One place to look is at npfs/spfs which is maintained as a sourceforge project. There are some incomplete developer works articles on using it via my blog (http://www.graverobber.org) -eric On 6/28/07, Enrico Weigelt [EMAIL PROTECTED] wrote: Hi folks, I'd like to write some small 9P2000 servers on Linux. What do I need for that ? Thx -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
Re: [9fans] Plan9 BOF
On 6/21/07, Skip Tavakkolian [EMAIL PROTECTED] wrote: can someone post a summary? There was a vendor that left beer and wine for us, so there were half-drunken demos (which are better than drunken half-demos) of the Blue Gene stuff and some discussions about why we are doing it. We talked briefly about the GSoC projects (mostly just making folks aware of them). I think Lucho meant to bring up more of the stuff he's doing with KVM, but it probably wasn't the right crowd. -eric
Re: [9fans] usenix
On 6/13/07, ron minnich [EMAIL PROTECTED] wrote: On 6/13/07, Charles Forsyth [EMAIL PROTECTED] wrote: bof? yeah, bof. oh hey, we have to set it up. So I asked for this: BoF title: Plan 9 Organizer name and affiliation: Ron Minnich, sandia labs Date, time, and location preference: tuesday, june 19, san tomas, 8-9pm Brief description of BoF (optional) For all you 9fans Do we really want to do it Tuesday? Will most conference attendees even be in that night? -eric
Re: [9fans] 9os?
On 5/16/07, Federico Benavento [EMAIL PROTECTED] wrote: I was googling around when I found this: http://9os.org my question is: wtf? f%ck off! Where' the People's Front of Judea -eric
Re: [9fans] 9os?
On 5/16/07, Eric Van Hensbergen [EMAIL PROTECTED] wrote: On 5/16/07, Federico Benavento [EMAIL PROTECTED] wrote: I was googling around when I found this: http://9os.org my question is: wtf? f%ck off! Where' the People's Front of Judea ummm...make that: We're the People's Front of Judea... -eric
Re: [9fans] 9os?
On 5/16/07, Skip Tavakkolian [EMAIL PROTECTED] wrote: f%ck off! We're the People's Front of Judea... Oh! I thought we were the Popular Front. E: PEOPLE'S FRONT! S: Whatever happned to the Popular Front? E: He's over there. A: LLIE!
Re: [9fans] THX hell
On 5/1/07, ron minnich [EMAIL PROTECTED] wrote: it's interesting to run this stuff by hand, and just see what a tangle web we have weave'd over 15 years. It's been a while since I watched x apps this closely. Xterm opens about 50 libs, while failing to open about 300. This would actually make a pretty great paper - detailing just how much crap has built up and become interdependent over time. -eric
Re: [9fans] speaking of kenc
On 4/28/07, Lucio De Re [EMAIL PROTECTED] wrote: No, but you're not going to like the reason. AFAIK nobody misses it, because there may not be a single HPC app in widespread use that could be run on Plan 9 today. We've been looking. Roman knows more than I do on this issue. But the question would be whether those applications do use complex types and thus adding them to KenCC would bring them closer to porting to Plan 9. At least, that seems a legitimate question. What Ron is saying is that the problem with making most HPC apps work on Plan 9 are not C language features -- its the lack of support for popular languages for doing HPC work. Fortran is the 1000 lbs gorilla here, although there are quite a few C++ codes as well. The second problem is the lack of support for certain libraries -- like OpenMP and MPI -- which are heavily reliant on POSIX features that are the least compatible with Plan 9 (posix threads, BSD sockets, signals, mmap, etc.) Or are you saying that no HPC app comes even remotely close to being portable? There are multiple degrees of portability. Most of the world considers POSIX the portability layer (and APE won't cut it on our end for the reasons stated above). But even then, HPC apps are large and complex beasts -- most take a few weeks to a month to figure out how to compile and tune even on a standard system. The problem is there is increasingly less diversity on the UNIX OS space, so the standard is rapidly moving from POSIX to Linux/X11. -eric
Re: [9fans] speaking of kenc
On 4/28/07, Rodrigo Miranda [EMAIL PROTECTED] wrote: There's Fortress being developed by Guy Steele at Sun, and others (IBM has one as well). http://fortress.sunsource.net/ IBM's is X10 (http://domino.research.ibm.com/comm/research_projects.nsf/pages/x10.index.html) -- but like Fortress, its so new that there isn't much of an existing install base and it remains to be seen if there ever will be. Cray also has been working on a new langauge called Chapel (http://chapel.cs.washington.edu/) All three (Chapel, Fortress and X10) were developed for the DARPA HPCS program. -eric
[9fans] import(1) -B and aan(8)
Anyone have an incantation for making import -B work with aan? -eric
[9fans] lmbench/hmbench on Plan 9
Back in 1999, Celio ran hmbench against Plan 9 and reported some comparisons to Linux. Did his port of hmbench ever make it to sources/contrib or anywhere else? -eric
Re: [9fans] CA Bay Area Plan9 users group
USENIX BoF in June in Santa Clara? -eric On 4/11/07, Lawrence E. Bakst [EMAIL PROTECTED] wrote: Does anyone who wants to attend live or work in the Pleasanton or Hayward areas and might be able to contribute a location there? They are both nice halfway points for almost everyone in the Bay area. I *might* be able to find something in Pleasanton. Give me a few days. Best, leb At 4:32 PM -0700 4/10/07, ron minnich wrote: I'm going to look for a place we can meet. I will let you know. Warning, my first choice will be livermore, since I live here :-) ron
Re: [9fans] qemu, kvm, xen
On 4/6/07, ron minnich [EMAIL PROTECTED] wrote: boot: qemu, 60 seconds kvm, 100 seconds (yes, indeed, kvm did indeed boot more slowly than plain old qemu) xen, 6 seconds (it's nice) build a pccpuf kernel: qemu, 100 seconds kvm, 80 seconds xen, 12 seconds So, the choice for speed is still xen. THX will remain xen-based for now. I/O is really going to suck with KVM right now -- after all, they are using qemu for all their I/O emulation, so it makes sense that they would be as slow. The fact that boot is almost double qemu is kinda crazy (is that qemu + kqemu, or vanilla qemu?) -- I mean I know they are setting up some extra shit, but double the time is nuts. kvm will catch up as soon as better paravirtualization interfaces are integrated (particularly for I/O) -- this is why I wanted to push 9p as the KVM paravirtualized I/O interface -- its clear they need to close that gap. -eric
[9fans] something more simple than import(1) -B
Probably a stupid question -- there seems like there should be a simple way to take stdin/stdout and generate a srv file -- such that I could aux/listen1 tcp!*!someport srvit -b somesrvname import -B sorta does this, but it does too much, it shoves authentication down my throat and also wants to mount it to some mount point instead of giving me a nice srv file. Is there some more simple command I'm missing, or is this just something that needs to be written? Similarly, Inferno doesn't really seem to have the concept of an import -B, which seems kinda of annoying. -eric
Re: [9fans] something more simple than import(1) -B
On 4/5/07, Russ Cox [EMAIL PROTECTED] wrote: On 4/5/07, Eric Van Hensbergen [EMAIL PROTECTED] wrote: Probably a stupid question -- there seems like there should be a simple way to take stdin/stdout and generate a srv file -- such that I could aux/listen1 tcp!*!someport srvit -b somesrvname aux/listen1 tcp!*!someport rc -c 'echo -n 0 /srv/somesrvname' Guess I was getting too hung up on stdin and stdout being different fd's like a boofhead. Thanks Russ. -eric
Re: [9fans] writing 9p servers and clients under gnu/linux
On 3/30/07, Enrico Weigelt [EMAIL PROTECTED] wrote: I'd like to do some experiments with 9p and write some little servers and clients for running on Unix systems (ie. GNU/Linux). There are some packages (ie.u9fs and npfs) but they neither worked for me, nor did I find any documentaion :( Any tips ? You really want spfs (which is under the npfs directory). Either Lucho or I can help you with any problems you are having. I also have some half-formed developer works articles on writing file systems with npfs that I can send you. -eric
Re: [9fans] qemu mouse
On 3/19/07, Russ Cox [EMAIL PROTECTED] wrote: you probably need to set mouseport=ps2 instead of mouseport=ps2intellimouse in plan9.ini. or something like that -- plan 9 and qemu certainly disagree about what the protocol is. mouseport is ps2, I'll try and free up some cycles to dig into it this week and see if I can figure out what's going on. -eric
Re: [9fans] coraid ethernet console
On 3/19/07, Russ Cox [EMAIL PROTECTED] wrote: 1. consolefs doesn't yet speak cec. (good soc project.) as long as you have a cec client that presents a file, consolefs should be able to read it. consolefs doesn't speak serial either. what is the relation between cec and this ethernet console? http://www.usenix.org/events/usenix03/tech/freenix03/kistler.html it would be nice if they could use the same protocols, though i don't know how complicated the freenix one is. ericvh? The freenix one was pretty dead stupid/simple. It just set the protocol to 0x0666. To my knowledge, no one outside of us has every really used the freenix console, although I did get a few requests for the code over the years. is the protocol documented somewhere other than the code? Nope. security? Nope - I believe the paper makes the argument that you could use VLANs to enforce security, but our primary use for the ethernet-based console was purely pragmatic -- the hardware we had didn't have serial, video, or any other means of getting output. -eric
Re: [9fans] interesting potential targets for plan 9 and/or inferno
On 3/7/07, ron minnich [EMAIL PROTECTED] wrote: On 3/6/07, Vester Thacker [EMAIL PROTECTED] wrote: Well, I apologize for offending you. But what ideas are you suggesting that we migrate toward? There are all sorts of different Plan 9's -- a) There is Plan 9 the research operating system, a small, well-written kernel that's extremely portable, easily understood, and fairly easy to extend and work with. It doesn't have as many features as other modern operating systems, but in a way that is how it has maintained its simplicity and relative stability. b) There is Plan 9 the distributed system - an elegant approach designed from the ground up to deal with a networked world. c) Then there's Plan 9 the terminal, a highly productive, very lightweight, and somewhat quirky interface which is more or less like nothing a typical user has ever seen before. As evidenced by this thread -- some love it, some hate it, some tolerate it, but most learn to love it -- particularly as a development environment. If you want a proper terminal environment under other operating systems you can run drawterm or plan9ports and it gets you most of the way there. There seem to be three major classes of gripes with Plan 9 the terminal: it doesn't support my devices (which drawterm largely overcomes), it doesn't run (or run with) my application/editor/browser (which can be somewhat overcome with plan9ports), its different and/or ugly. The different part is something many of us love, the ugly part is something many of us don't care about -- both largely revolve around the window manager and applications versus anything inherent in the operating system. d) There's also Plan 9, the tools - by which I primarily mean ken cc -- which works well enough for the platforms they support, are extremely quick, and were well understood (by Ken, and now by forsyth). In my opinion work on (a) and (b) constitutes operating systems research -- and there's plenty to do, particularly to support demanding customers with tens of thousands of nodes in a scalable and efficient manner. Plan 9 just hasn't been stressed at those levels before. There's nothing wrong with working on (c) or (d) -- stuff like Plan B has shown us there's plenty of room for interesting exploration and improvement -- but those are more about working on applications versus working on the environment. In other words, they really are projects onto themselves, not Plan9 per se -- in much the same way that gnome != linux, rio != plan9. So if someone wants to go out and write a new window manager (or port an existing one to Plan 9) more power to them, and more choice to us. However, I really don't think this should be a primary concern. Ron is concerned (as am I) about keeping certain funding sources happy -- and part of that is getting people at our organizations to use Plan 9. However, I think we should be focusing on getting them to use Plan 9 (a) and Plan 9 (b). Any discussion of (c) (and potentially (d)) will just turn religious and its not worth having that inquisition one way (convince them to use our interfaces) or the other (jam their interfaces into Plan 9). My opinion is that time would be better spent with focusing on the core of (a) and (b) and accomodating end-users who don't like the Plan 9 interface by providing gateways into Plan 9 systems from their (existing) desktop environments -- meaning things like plan9ports, xcpu, v9fs, etc. The issue of tools (d) is still complicated, particularly with people plugging scripting languages like python into their HPC applications -- but that's a battle that's more worth fighting than a battle over marketing eye candy and wanting to rung Mozilla inside Plan 9. -eric
Re: [9fans] interesting potential targets for plan 9 and/or inferno
On 3/7/07, erik quanstrom [EMAIL PROTECTED] wrote: thanks for the well considered post. i would add (somewhat less articulately) (e) 9p appliances That's certainly fair. I was thinking as well that there probably should be some extra category for embedded to cover scenarios like the iPaq or Ron's open-phones. The truth is that its really almost its own sub-domain with aspects relating to terminals, distributed systems, and server appliances (for example, sensor networks and motes and what not would probably fit into the server appliance class, but a proper phone would be more like a terminal). -eric
Re: [9fans] interesting potential targets for plan 9 and/or inferno
On 3/6/07, matt [EMAIL PROTECTED] wrote: fuck 'em! I think that's a great name for our next GUI -eric
Re: [9fans] interesting potential targets for plan 9 and/or inferno
On 2/26/07, ron minnich [EMAIL PROTECTED] wrote: On 2/26/07, erik quanstrom [EMAIL PROTECTED] wrote: plan 9 is having trouble keeping the converted. why would adding one more layer of goo to the gnu goo stack convert the hardened of heart? Because the first thing that most people say when I show them rio is 'yuck'. And, in most cases, they don't stop saying 'yuck'.Acme does not help. Sorry, but most people hate the Plan 9 GUI. It is off-putting enough that they are not that interested in seeing the beauty of it all. Regardless, neither rio or acme will work well on a cell phone. Probably be best off with mux. However, I think we can all agree -- while the underlying infrastructure of the Plan 9 GUI continues to be innovative and interesting, the GUI itself has never been a focus nor a strength of the system. I'm not saying we should merge Qt and Gtk or any of the Linux variants -- I continue to think we need to focus on our strengths rather than getting bogged down in eye candy. -eric
Re: [9fans] interesting potential targets for plan 9 and/or inferno
On 2/25/07, erik quanstrom [EMAIL PROTECTED] wrote: without the specs, you're locked into using their sdk, libraries, gcc, gnu shared libraries, their linux kernel, etc. i think by unlimited software development they mean application-level software development on the kernel we give you. While this impacts doing Plan 9 development, doesn't interfere with Inferno... -eric
Re: [9fans] Question about v9fs on Gentoo
Which kernel version? Or better yet, cat /proc/filesystems with the v9fs module installed. You'll see either 9P2000, 9P, or 9p depending on kernel version, then you should be able to use that as the argument to mount -t (ie. mount -t 9p 127.0.0.1) There was some unfortunate churn in the naming of the fs, but we've now settled on 9p. -eric On 2/22/07, Adriano Verardo [EMAIL PROTECTED] wrote: Hi, all. I've configured Gentoo' v9fs without any problems (both dynamic and in-kernel) but I cannot use it because the mount utility doesn't recognize the 9P file system type. Where can I find the correct mount util ? From p9p ? Thanks.
Re: [9fans] Question about v9fs on Gentoo
Can you send me a dump of your command line, also try once with debug enabled: mount -t 9p 127.0.0.1 /mnt -o debug=0xf On 2/22/07, Adriano Verardo [EMAIL PROTECTED] wrote: Eric Van Hensbergen wrote: Which kernel version? kernel-genkernel-x86-2.6.19-gentoo-r5
Re: [9fans] Question about v9fs on Gentoo
On 2/22/07, Adriano Verardo [EMAIL PROTECTED] wrote: ron minnich wrote: Sorry, I was saying ... I tried both 9p and 9P. I don't know whether or not there is a specialized mount utils, as in FreeBSD. If not, IMHO, mount should recognize the available fs from /proc. 9p is not listed in /proc/filesystem, also when statically linked in the kernel. I think It should be. If there is no 9p, 9p2000, or 9P in /proc/filesystems, there is something wrong with the way you have built your kernel or kernel module. When you compile it as a module and than insmod it, do you see anything funny in /var/log/messages or dmesg? -eric
Re: [9fans] Question about v9fs on Gentoo
On 2/22/07, Adriano Verardo [EMAIL PROTECTED] wrote: Eric Van Hensbergen wrote: On 2/22/07, Adriano Verardo [EMAIL PROTECTED] wrote: ron minnich wrote: Sorry, I was saying ... I tried both 9p and 9P. I don't know whether or not there is a specialized mount utils, as in FreeBSD. If not, IMHO, mount should recognize the available fs from /proc. 9p is not listed in /proc/filesystem, also when statically linked in the kernel. I think It should be. If there is no 9p, 9p2000, or 9P in /proc/filesystems, there is something wrong with the way you have built your kernel or kernel module. I see. When you compile it as a module and than insmod it, do you see anything funny in /var/log/messages or dmesg? I tried all possible ways to configure 9p. Loadable module: 9p is in the lsmod output. In-Kernel: in /var/log/dmesg I see Activated 9P2000 ... In any case: - no reference in /proc/filesystem - mount -t 9p 127.0.0.1 /mnt -o debug=0xf - Unknown file system type '9p' Just realized there was a bug I fixed a while back 9p: fix bogus return code checks during initialization which is probably causing your problem. It went in Jan 26th, 2007, which would have been well after 2.6.19 was out. If its easy, upgrade to 2.6.20 and the problem should go away, if that isn't easy, backport just the fs/9p from 2.6.20 to 2.6.19. This was my bad -- there was a period between 2.6.17 and 2.6.20 where I didn't do a good job regressing stuff, and some bogus return-code checks slipped in which screw up initialization. -eric
[9fans] Calling all students
It's the time of year again where we (IBM Research) starts recruiting for our summer internship programs. I am looking for graduate students out there who are looking for summer employment (in Austin, TX) working on Plan 9, Inferno, and related technologies. Based on funding prospects this year, its quite likely I'll be able to place folks working on the Blue Gene Plan 9 port or something related to my library operating system work (http://www.research.ibm.com/prose) -- most likely working on an Inferno-based library operating system kernel. We also have a number of longer term co-op positions (also for graduate students), which would typically run from 6 months to a year. If you are interested in either of these two types of positions, drop me a resume and letters of recommendation sometime within the next couple of weeks. -eric
Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow
On 12/12/06, ron minnich [EMAIL PROTECTED] wrote: On 12/12/06, Bruce Ellis [EMAIL PROTECTED] wrote: Browser, buy a cheap PC and run whatever you like on it. Wow that solves everything. That was a good session. brucee sucks for laptops though. I hate carrying all them thar laptops -- they get in the way of my shootin' iron. Just need to put your experience of building small systems towards building a headless laptop-server -- then you can use drawterm from your browser laptop - or home desktop, or whatever. It'd be sweet to have something I could power off of USB 2.0 or battery, with a hard drive and wireless (and maybe a serial port for jmk). Gumstick seems like it comes close - but no real solution for portable or piggy-back power. I suppose an iPaq might be able to be tasked to such a solution as well -- but has less than ideal disk storage. Neither has particularly glorious CPU power or memory -- maybe we can build something with the OLPC mother boards sans screen/keyboard. -eric
Re: [9fans] some snapshots of iwp9
On 12/12/06, ron minnich [EMAIL PROTECTED] wrote: On 12/11/06, Lyndon Nerenberg [EMAIL PROTECTED] wrote: Just put 'em on an FTP server somewhere. Nobody on this list owns a web ^^^ ewww. How do we do anonymous 9p? contrib/papers on sources? I was thinking next workshop registration and paper submission should be a 9p-only affair. -eric
Re: [9fans] UBUNTU and v9fs
On 12/12/06, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Tue, Dec 12, 2006 at 05:35:58PM +0200, Lucio De Re wrote: Does the wiki have instructions on how to make UBUNTU (Dapper Drake) speak v9fs? It seems to me that I need a recompiled kernel and I'm not familiar enough with the procedure to upgrade the system at that level. You don't need to do anything, just ; modprobe 9p2000 or ; modprobe 9p Default Dapper has an older, buggier version of v9fs (2.6.15). Edgy has a much more reasonable version (2.6.17). -eric
Re: [9fans] IWP9 talks?
I can probably pull resources together to host here in Austin at IBM, but I'd rather go to Sydney :) -eric On 12/11/06, Bruce Ellis [EMAIL PROTECTED] wrote: Sydney? I can probably get it together. brucee On 12/10/06, Gorka guardiola [EMAIL PROTECTED] wrote: On 12/8/06, Paul Lalonde [EMAIL PROTECTED] wrote: A big thank-you to the organizers, and to Gorka especially for finding a restaurant to seat 30 on short notice. Fabulous to meet you all. Thank you all back for coming. A great way to show your gratitude is offering yourselves for hosting next year's. Anyone??? -- - curiosity sKilled the cat
Re: [9fans] v9fs
On 11/2/06, Skip Tavakkolian [EMAIL PROTECTED] wrote: is there a test rig to verify v9fs -rfdno/-wfdno? What exactly are you looking for? i wanted to see how -rfdno/-wfdno should be used. ideally it would be something that does the p9any auth and hands the fd's to v9fs. Closest thing I can think of is Lucho's amount appication (available via v9fs CVS repo on sourceforge), although there may be something more up-to-date available now. Lucho? -eric
Re: [9fans] v9fs
Looks like Lucho's response didn't make it to the list: You can check np_pipesrv_mount function in libnpfs source code. http://npfs.cvs.sourceforge.net/npfs/npfs/libnpfs/pipesrv.c?revision=1.3view=markup On 11/2/06, Skip Tavakkolian [EMAIL PROTECTED] wrote: is there a test rig to verify v9fs -rfdno/-wfdno? What exactly are you looking for? i wanted to see how -rfdno/-wfdno should be used. ideally it would be something that does the p9any auth and hands the fd's to v9fs.
