Re: [9fans] Adventures of a home user
My Plan 9 training is temporarily suspended while I learn to use QEMU. That's funny because I suspended my Slackware training to learn to use Plan 9. Now I might suspend my QEMU training to try out some other virtualizers. Also, I got a FreeDOS image to use for my QEMU training, so I may wander off into FreeDOS for a while.
Re: [9fans] Adventures of a home user
To whom it may concern: had the right patches for Plan 9 to work on Virtual PC been incorporated and a new ISO released half the complaints from Windows users who want to give Plan 9 a try would disappear. Some potential enterprise users might also get interested in running many Plan 9 instances on Microsoft Virtual Server platform after seeing it run on Virtual PC (Due to its light weight Plan 9 may be a good choice for some virtual hosting services). P.S. No need to remind me the originator of this thread is trying Plan 9 on a VM in Linux. He has a working Windows installation anyway and configuring Virtual PC for networking (or any task) is way easier than QEMU. Performance is comparable. Plus, VPC's graphics and guest-host integration work perfectly. --On Thursday, April 23, 2009 5:12 PM +0800 Jim Habegger jimhabeg...@gmail.com wrote: My Plan 9 training is temporarily suspended while I learn to use QEMU. That's funny because I suspended my Slackware training to learn to use Plan 9. Now I might suspend my QEMU training to try out some other virtualizers. Also, I got a FreeDOS image to use for my QEMU training, so I may wander off into FreeDOS for a while.
[9fans] (no subject)
Hi, I have decided to try to cross compile to windows again, as I see it here are my options: 1) build mingw for plan9 This means getting gcc to compile under kenc - non-trivial 2) build lcc on plan9 ditto 3) build pcc for plan9 ditto (though nothing like as bad as the above) sadly pcc needs yasm or mingw-as + mingw ar and mingw ld so I don't win much. 4) write a parser to understand windows header files and generate assembly wrappers so I can use kenc. Then I just need to build a PE executable backend. 4 seems the most attractive, however I believe all windows executables are still relocatable, but this feature is rarely used by the XP/Win2k3 etc. anyone know any more. anyone know of any other (simpler) options? I guess my ultimate sanction might be mingw for Linux running under linuxemu though this feels a bit of a copout. -Steve
Re: [9fans] Plan9 - the next 20 years
Not to beat a (potentially) dead horse (even further) to death, but if we had some way of knowing that files were actually data (i.e. not ctl files; cf. QTDECENT) we could do more prefetching in a proxy -- e.g. cfs could be modified to do read entire files into its cache (presumably it would have to Tstat afterwards to ensure that it's got a stable snapshot of the file). Adding cache journal callbacks would further allow us to avoid the RTT of Tstat on open and would bring us a bit closer to a fully coherent store. Achieving actual coherency could be an interesting future direction (IMHO). you're right. i think cfs is becoming a pretty dead horse. if you're running at a significant rtt from your main system, and you don't have one of your own, the simple solution is to install 9vx. that way your system is local and only the shared files get shared. does cfs even work with import? if it doesn't then using it implies that all your data are free for public viewing on whatever network you're using, since direct fs connections aren't encrypted. regarding the QTDECENT, i think russ is still on point http://9fans.net/archive/2007/10/562 - erik
Re: [9fans] (no subject)
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.
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] roots
where do they think linux, minux, unix came from? “ It rarely leads to good things when a small community gets headed off in their own direction, he [lwn editor j. corbet] said. — http://lwn.net/Articles/327938/ - erik
[9fans] Git Mirror
I've started a public nightly mirror of (the source code bits) from sources using github: http://github.com/ericvh/plan-9/tree/master (There's also a mirror of inferno-os from google code: http://github.com/ericvh/inferno-os/tree/master I started this primarily for my personal use, but as they are public I figured I'd let you folks know. Feel free to use or ignore them. If you feel there are important parts I'm missing, let me know and I'll add it to the proto file (for the Plan 9 case) -eric
[9fans] missing ed's line numbering in sam -d
Hello, when using 'sam -d' to remotely edit files I really miss the option to print line numbers along with lines, like ed's e.g. '1,10n'. Is there anything like that? Why not? Thanks Ruda
Re: [9fans] missing ed's line numbering in sam -d
you can do this in sam with an external program
; cat /bin/nl
#!/bin/rc
if(~ $#* 0)
awk '{printf(%4d %s\n, ++lineno, $0);}'
if not for(i)
awk '{printf(%4d %s\n, ++lineno, $0);}' $i
; sam -d /lib/volcanoes
1,10nl
1 This nice little file came from the Smithsonian.
2 Doug McIlroy
3
4 SMITHSONIAN INSTITUTION
5 GLOBAL VOLCANISM PROGRAM
6 NHB MRC 119, Washington, DC 20560
7
8VOLCANOES OF THE WORLD - 1992
9
10
!
- erik
Re: [9fans] missing ed's line numbering in sam -d
2009/4/23 erik quanstrom quans...@quanstro.net: you can do this in sam with an external program ... except the line numbers won't be accurate unless you're printing lines from the beginning.
Re: [9fans] missing ed's line numbering in sam -d
On Thu Apr 23 11:36:09 EDT 2009, rogpe...@gmail.com wrote: 2009/4/23 erik quanstrom quans...@quanstro.net: you can do this in sam with an external program ... except the line numbers won't be accurate unless you're printing lines from the beginning. left as an excercize to the reader. - erik
Re: [9fans] Adventures of a home user
Some potential enterprise users might also get interested in running many Plan 9 instances on Microsoft Virtual Server platform after seeing it run on Virtual PC (Due to its light weight Plan 9 may be a good choice for some virtual hosting services). might makes right ?
Re: [9fans] missing ed's line numbering in sam -d
2009/4/23 erik quanstrom quans...@coraid.com: left as an excercize to the reader. not possible, i think, as the external program can't know where the sam selection is coming from. easier in acme.
Re: [9fans] missing ed's line numbering in sam -d
On Thu Apr 23 12:06:23 EDT 2009, rogpe...@gmail.com wrote: 2009/4/23 erik quanstrom quans...@coraid.com: left as an excercize to the reader. not possible, i think, as the external program can't know where the sam selection is coming from. easier in acme. totally impossible to do acme -d. otoh, since . can be known by the user in sam -d, one could modify the script so that 19,29nl -s19 works as expected. - erik
[9fans] 9p2010
it occurred to me yesterday morning that the problem with a bundle of 9p requests is that 9p then no longer maps directly to system calls. with 9p2000, if you want to do a Tread, it's pretty clear that one needs to read(2); traditiona syscalls map directly to 9p. not so when bundles/sequences are introduced. how does a user program generate an arbitrary bundle? can programs use bundles at all without being rewritten? - erik
Re: [9fans] missing ed's line numbering in sam -d
The underlying problem is that sam is simply not line-oriented. If you're doing things with a file which is naturally thought of a series of lines then ed is usually better than sam -d. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] Plan9 - the next 20 years
On Sat, Apr 18, 2009 at 08:05:50AM -0700, ron minnich wrote: For cluster work that was done in the OS, see any clustermatic publication from minnich, hendriks, or watson, ca. 2000-2005. FWIW, I haven't found much left, and finally purchased your (and al.) article about HARE: The Right-Weight-Kernel... Since it considers, among others, Plan 9, it's of much interest for me ;) What impresses me much is the state of the open source cluster solutions from a rapid tour. clustermatic: not much left from lanl openmosix: closed beowulf: seems to have stalled a little since 2007 kerrighed: After 8 years of research it is considered a proof of concept, but for obtaining a stable system, we have disabled some features. I hope that the last [from memory] quotes do not imply that the old way of disproving an assertion by a counter-example has been replaced by considered proved an assertion by advertising a limited not crashing too fast example. -- Thierry Laronde (Alceste) tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] (no subject)
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. ... and when I eventually completed it under NetBSD, a few months back, the GAS pass failed with a segmentation violation. I wonder if it's been fixed since... ++L
Re: [9fans] (no subject)
back, the GAS pass failed with a segmentation violation. unfortunate! that's gotta hurt. ☺ - erik
Re: [9fans] 9p2010
2009/4/23 erik quanstrom quans...@quanstro.net:
it occurred to me yesterday morning that the problem with
a bundle of 9p requests is that 9p then no longer maps directly
to system calls.
with 9p2000, if you want to do a Tread, it's pretty clear that
one needs to read(2); traditiona syscalls map directly to 9p.
true, but it is a one-to-many mapping - for instance, a single call to
open may generate an arbitrary number of 9p messages.
not so when bundles/sequences are introduced. how does a
user program generate an arbitrary bundle? can programs
use bundles at all without being rewritten?
this is an interesting question.
as a starting point, i'd envisaged simply changing the existing
system calls to do sequences.
in inferno, where it's easy to add system calls, it would be
straightforward, i think, to add some additional system-level primitives,
(e.g. readfile) that took advantage of sequencing.
but that is cheating really - ideally you'd want a user-level
interface to this functionality.
the difficulty with creating the interface is that a 9p call
must be separated into two parts - the sending of the
parameters and the retrieving of the results.
for a low level 9p interface, i'd imagined something like
the following interface (in pseudo limbo):
Sequence: adt {
queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
cont: fn(seq: self ref Sequence);
flush: fn(seq: self ref Sequence);
}
queue adds a new message to the sequence (with an arbitrary
tag to attach to the result of the call). wait waits for the next
reply to come in and returns the tag, the originating tmsg and the
reply. cont continues executing a sequence after it has
been aborted due to error (this will resend tmsgs). flush aborts
the sequence.
so this is ok when dealing with 9p or the dev interface directly, but
won't work so well
with higher level calls. it would be nice for a user-level program to
be able to string together an arbitrary sequence of system calls
into a sequence, but i'm not sure what a decent interface would look like.
(something like the above Sequence adt, but with a system call description
instead of Tmsg and a system call result instead of Rmsg, perhaps,
although it's not clear what a system call description would look like,
or how easy it would be to split system calls)
the control flow is not straightforward (or perhaps it is - it's the kind
of thing that might just have a nice elegant solution lurking there somewhere).
something to think about.
Re: [9fans] (no subject)
On Thu, Apr 23, 2009 at 10:17 AM, erik quanstrom quans...@quanstro.netwrote: back, the GAS pass failed with a segmentation violation. unfortunate! that's gotta hurt. ☺ - erik Seems like you'd have to change your pants after a GAS pass segmentation violation.
Re: [9fans] 9p2010
as a starting point, i'd envisaged simply changing the existing
system calls to do sequences.
[...]
Sequence: adt {
queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
cont: fn(seq: self ref Sequence);
flush: fn(seq: self ref Sequence);
}
this is significantly more complicated than syscalls.
- erik
Re: [9fans] 9p2010
But if you do that (send sequences from userl-level)
you must interpret your namespace yourself. When I tried to
detect how to bundle calls for plan b, a problem I had was
namec. For me it's still not clear how to detect cleanly
`what to batch', even if you change the source for the
program doing I/O to help there, because of the mount
table.
From: rogpe...@gmail.com
To: 9fans@9fans.net
Reply-To: 9fans@9fans.net
Date: Thu Apr 23 19:26:06 CET 2009
Subject: Re: [9fans] 9p2010
2009/4/23 erik quanstrom quans...@quanstro.net:
it occurred to me yesterday morning that the problem with
a bundle of 9p requests is that 9p then no longer maps directly
to system calls.
with 9p2000, if you want to do a Tread, it's pretty clear that
one needs to read(2); traditiona syscalls map directly to 9p.
true, but it is a one-to-many mapping - for instance, a single call to
open may generate an arbitrary number of 9p messages.
not so when bundles/sequences are introduced. how does a
user program generate an arbitrary bundle? can programs
use bundles at all without being rewritten?
this is an interesting question.
as a starting point, i'd envisaged simply changing the existing
system calls to do sequences.
in inferno, where it's easy to add system calls, it would be
straightforward, i think, to add some additional system-level primitives,
(e.g. readfile) that took advantage of sequencing.
but that is cheating really - ideally you'd want a user-level
interface to this functionality.
the difficulty with creating the interface is that a 9p call
must be separated into two parts - the sending of the
parameters and the retrieving of the results.
for a low level 9p interface, i'd imagined something like
the following interface (in pseudo limbo):
Sequence: adt {
queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
cont: fn(seq: self ref Sequence);
flush: fn(seq: self ref Sequence);
}
queue adds a new message to the sequence (with an arbitrary
tag to attach to the result of the call). wait waits for the next
reply to come in and returns the tag, the originating tmsg and the
reply. cont continues executing a sequence after it has
been aborted due to error (this will resend tmsgs). flush aborts
the sequence.
so this is ok when dealing with 9p or the dev interface directly, but
won't work so well
with higher level calls. it would be nice for a user-level program to
be able to string together an arbitrary sequence of system calls
into a sequence, but i'm not sure what a decent interface would look like.
(something like the above Sequence adt, but with a system call description
instead of Tmsg and a system call result instead of Rmsg, perhaps,
although it's not clear what a system call description would look like,
or how easy it would be to split system calls)
the control flow is not straightforward (or perhaps it is - it's the kind
of thing that might just have a nice elegant solution lurking there
somewhere).
something to think about.
Re: [9fans] 9p2010
On Thu, Apr 23, 2009 at 10:28 AM, erik quanstrom quans...@quanstro.netwrote:
as a starting point, i'd envisaged simply changing the existing
system calls to do sequences.
[...]
Sequence: adt {
queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
cont: fn(seq: self ref Sequence);
flush: fn(seq: self ref Sequence);
}
this is significantly more complicated than syscalls.
- erik
Are we doing all of this to defeat the conveniences we get from the
statefulness of 9p? Would a stateless 9p-like protocol be better (no
walks)? Is a stateless 9p really HTTP? :-)
If those are all yeses, are we re-inventing the wheel? Or does 9p or some
derivative really have to get used everywhere? :-)
I mean if we figure this out, great, but if not, I think we're still ok,
just can't use 9p right? :-)
Re: [9fans] 9p2010
2009/4/23 Fco. J. Ballesteros n...@lsub.org: But if you do that (send sequences from userl-level) you must interpret your namespace yourself. When I tried to detect how to bundle calls for plan b, a problem I had was namec. For me it's still not clear how to detect cleanly `what to batch', even if you change the source for the program doing I/O to help there, because of the mount table. i guess that the current design of the walk message shows what can be batched, but i agree, the mount table is at the core of the issue. i wonder how many things would break if plan 9 moved to a strictly name-based mapping for its mount table...
Re: [9fans] 9p2010
On Apr 23, 2009, at 12:26 PM, erik quanstrom wrote: with 9p2000, if you want to do a Tread, it's pretty clear that one needs to read(2); traditiona syscalls map directly to 9p. It seems to me that the syscall interface is by design different than the 9p2000 api: - most syscalls map to a sequence of 9p2000 messages (allocate a new fid, walk to the named resource, open/stat/remove) - open files are represented by file descriptors, not 9p2000 fids - file descriptors map to fids in a n - 1 relationship - file descriptors maintain a current offset - other than fids associated with file descriptors, the only other fid associated with a process is the current working directory (i.e. you can't cache the result of a Twalk other than via the current working directory) - there is no direct access to Twalk - the semantics of a process namespace is a non-trivial multiplexing of several 9p2000 namespaces I was reading through the source of exportfs the other day and it struck me that there was quite a bit of work involved in mapping incoming 9p2000 messages into syscalls within the process namespace (e.g., fids vs file descriptors, qid clashes).
Re: [9fans] 9p2010
Another alternative (maybe this has already been mentioned -- I
haven't been closely following the thread) -- is to integrate the
caching into a cache file system. That way you get the advantage for
static files (and static file systems) where you have the least
opportunity to shoot yourself in the foot by prefetching or making
assumptions. No new system calls, no necessary changes to the
libraries.
-eric
On Thu, Apr 23, 2009 at 12:22 PM, roger peppe rogpe...@gmail.com wrote:
2009/4/23 erik quanstrom quans...@quanstro.net:
it occurred to me yesterday morning that the problem with
a bundle of 9p requests is that 9p then no longer maps directly
to system calls.
with 9p2000, if you want to do a Tread, it's pretty clear that
one needs to read(2); traditiona syscalls map directly to 9p.
true, but it is a one-to-many mapping - for instance, a single call to
open may generate an arbitrary number of 9p messages.
not so when bundles/sequences are introduced. how does a
user program generate an arbitrary bundle? can programs
use bundles at all without being rewritten?
this is an interesting question.
as a starting point, i'd envisaged simply changing the existing
system calls to do sequences.
in inferno, where it's easy to add system calls, it would be
straightforward, i think, to add some additional system-level primitives,
(e.g. readfile) that took advantage of sequencing.
but that is cheating really - ideally you'd want a user-level
interface to this functionality.
the difficulty with creating the interface is that a 9p call
must be separated into two parts - the sending of the
parameters and the retrieving of the results.
for a low level 9p interface, i'd imagined something like
the following interface (in pseudo limbo):
Sequence: adt {
queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
cont: fn(seq: self ref Sequence);
flush: fn(seq: self ref Sequence);
}
queue adds a new message to the sequence (with an arbitrary
tag to attach to the result of the call). wait waits for the next
reply to come in and returns the tag, the originating tmsg and the
reply. cont continues executing a sequence after it has
been aborted due to error (this will resend tmsgs). flush aborts
the sequence.
so this is ok when dealing with 9p or the dev interface directly, but
won't work so well
with higher level calls. it would be nice for a user-level program to
be able to string together an arbitrary sequence of system calls
into a sequence, but i'm not sure what a decent interface would look like.
(something like the above Sequence adt, but with a system call description
instead of Tmsg and a system call result instead of Rmsg, perhaps,
although it's not clear what a system call description would look like,
or how easy it would be to split system calls)
the control flow is not straightforward (or perhaps it is - it's the kind
of thing that might just have a nice elegant solution lurking there
somewhere).
something to think about.
Re: [9fans] 9p2010
...integrate the caching into a cache file system this was discussed at one of the iwp9s I believe. Ok, a thought experiment. Extend fossil so that you can attach to objects of the form fs.changes (e.g. main.changes or other.changes). Open a known file here (e.g. /update) and you will receive a message when any file in main (or other in the above example) filesystem is modified. The message should probably be a dirstat structure and a flag indicating weather the file itself has changed or only the dirstat. The client could also read from the file /score and would get a venti score for the watched filesystem every time a snap is taken. To allow the system to synchronise after a period of disconnection the client could write a venti score to /score before opening /update to indicate that it needs to catch up the changes since this score's creation. It would allow cfs to serve up local files with the knowledge that the remote server contains the same file and so cfs would feel much mor responsive. Batched 9p messages would improve the performance further, of course. You could teach the cache client to use batched 9p from the begining, and end up with somthing similar to nemo's octopus. Note, the files I am describing are those served by fossil, so, by definition they are disk files, and thus they are cacheable. This is not a solution for virtual files. I'am sure there are problems with the above, but you get the idea. -Steve
Re: [9fans] (no subject)
anyone know of any other (simpler) options? Inferno utils? The binaries for NT? ++L
[9fans] Contrib index, snip
Folks: The contrib index on the wiki [1] hadn't been updated in a long time; I'm now automatically regenerating it nightly. I've made some minor changes to the script that does the updates; the most significant is that INDEX files can now describe files and directories arbitrarily deep in the tree, as opposed to only in their own level. More info on the wiki's contrib page [2]. Unrelated, about a month ago I put together snip, [3] a little pastebin-like service for sharing snippets of code (or whatever). Details on the snip's contrib page [4], but basic usage is snip /some/file to paste a snippet (/dev/snarf is a useful /some/file), which will return a path to the new snippet, or snip unadorned, which will list currently-available snippets. Snip's gotten decent use in IRC. I was originally planning on embellishing the server side a bit, but it's not really worth it. I'll move it from ramfs to disk on next reboot, and that'll be that. [1] http://plan9.bell-labs.com/wiki/plan9/Contrib_index/ [2] http://plan9.bell-labs.com/wiki/plan9/contrib/ [3] /n/sources/contrib/anothy/bin/rc/snip [4] http://plan9.bell-labs.com/wiki/plan9/snip/
