Re: [9fans] dataflow programming from shell interpreter
i don't think a direct mapping of COM to Plan 9 fs model is unnecessary. for example, instead of mapping every control or configuration interface and method to synthetic directories and files, a single ctl file will do. It didn't occur to me at all that anyone would want to implement DirectShow or anything like that on Plan 9. Anyhow, I suppose if anyone's going to do that they should probably first work on fast display drivers that leverage modern cards' overlay capabilities and a facilitating media infrastructure equivalent to DirectX. On run-of-the-mill PCs good video works depends a lot on software support of video hardware, of course. The logic inside most DirectShow filters either is open source (like ffdshow) or has good open source equivalents. The interfacing (COM), as you have noted, and input/output, which is hardware-dependent and therefore probably weakly developed in Plan 9 (I don't really have an idea, just guessing), are the missing bits from a DirectShow-like (multi-pipe) video processing pipeline on Plan 9. --On Thursday, January 21, 2010 13:36 -0800 Skip Tavakkolian 9...@9netics.com wrote: Aren't DirectShow filter graphs and programs like GraphStudio/GraphEdit one possible answer to the video processing question? Filter graphs can be generated by any program, GUI or CLI, and fed to DirectShow provided one learns the in and out of generating them. DirectShow is COM; source/mux/transform/sink filters must provide a number of interfaces (e.g. IFileSinkFilter); other components (e.g. GraphBuilder) are there to make it easier to hook them together. i don't think a direct mapping of COM to Plan 9 fs model is unnecessary. for example, instead of mapping every control or configuration interface and method to synthetic directories and files, a single ctl file will do. something like this seems sufficient: /ctl# e.g. accepts run, stop, etc. returns: paused, #outputs, config, etc./event # instead of callback notification /ipin/clone /ipin/n/ctl /ipin/n/event /ipin/n/data /opin/clone /opin/n/ctl /opin/n/event /opin/n/data for a special purpose kernel one could add a driver and a fancy new hook syscall (similar to pushssl and '#D') that would hook two fd's together to eliminate the need for a user proc to transfer between ipin/?/data and opin/?/data.
[9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY
Is anybody else currently using the ethervgbe driver? I'm had some problems with it which don't seem to be caused by my hardware. After receiving 256 packets I was getting: panic: freeb: ref -1; caller pc 0xf01b1754 panic: freeb: ref -1; caller pc 0xf01b1754 Turns out calling freeb was messing things up (so the second time through the block list the data went to bung blocks) and the workaround simple: 537c537 etheriq(edev, block, 1); --- etheriq(edev, block, 0); Now, those of you who know more about this than I, are there any side-effects of that? It seems to be working now... I also discovered (from the chipset manual) that the RX ring is apparently limited to 252 entries, but I'vn't made sure those 4 packets were indeed being dropped. I came across the missing PHY message in 9fans, and just wanted to put out there that I've only had the problem in the transition from Linux to Plan 9 (like when I was fetching docs for it), at which point removing power from the computer before booting fixed it. enjoy, tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY
I had the same problem and came to the same (kludgey) solution. The ethervgbe driver is still a bit of a work in progress. Other ethernet drivers use the same trick, a pool of Blocks that are never freed, but they use _xincref inside the driver proper to make sure etheriq(..., 1) doesn't cause a reference counting panic. That doesn't work in the vgbe driver for reasons I didn't have the time to explore. On the subject, if anybody's interested in pxe booting off a card supported by the ethervgbe driver, I have a preliminary 9load driver that you can use/debug. On Fri, Jan 22, 2010 at 11:33 AM, Tristan Plumb 9p...@imu.li wrote: Is anybody else currently using the ethervgbe driver? I'm had some problems with it which don't seem to be caused by my hardware. After receiving 256 packets I was getting: panic: freeb: ref -1; caller pc 0xf01b1754 panic: freeb: ref -1; caller pc 0xf01b1754 Turns out calling freeb was messing things up (so the second time through the block list the data went to bung blocks) and the workaround simple: 537c537 etheriq(edev, block, 1); --- etheriq(edev, block, 0); Now, those of you who know more about this than I, are there any side-effects of that? It seems to be working now... I also discovered (from the chipset manual) that the RX ring is apparently limited to 252 entries, but I'vn't made sure those 4 packets were indeed being dropped. I came across the missing PHY message in 9fans, and just wanted to put out there that I've only had the problem in the transition from Linux to Plan 9 (like when I was fetching docs for it), at which point removing power from the computer before booting fixed it. enjoy, tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY
That's the wrong fix; ethernet drivers should always call etheriq(edev, block, 1); The sole exception is in devether.c. ---BeginMessage--- Is anybody else currently using the ethervgbe driver? I'm had some problems with it which don't seem to be caused by my hardware. After receiving 256 packets I was getting: panic: freeb: ref -1; caller pc 0xf01b1754 panic: freeb: ref -1; caller pc 0xf01b1754 Turns out calling freeb was messing things up (so the second time through the block list the data went to bung blocks) and the workaround simple: 537c537 etheriq(edev, block, 1); --- etheriq(edev, block, 0); Now, those of you who know more about this than I, are there any side-effects of that? It seems to be working now... I also discovered (from the chipset manual) that the RX ring is apparently limited to 252 entries, but I'vn't made sure those 4 packets were indeed being dropped. I came across the missing PHY message in 9fans, and just wanted to put out there that I've only had the problem in the transition from Linux to Plan 9 (like when I was fetching docs for it), at which point removing power from the computer before booting fixed it. enjoy, tristan -- All original matter is hereby placed immediately under the public domain. ---End Message---
[9fans] find command reloaded
Hello,
I've been wondering.
The plan9 'replacement' for the (linux/unix-like) find command, according to
the faq, is, in a way,
grep foo `{du -a . | awk '{print $2}'}
Now I want to find all files containing foo.
Is it so that `{ ... } produces the full list first and only afterwards this
is used?
If so (and as I understand it really is so), the number of arguments may be
enormous, e.g. millions of names...
I don't feel this is the way to go...
How do you carry out such a search?
Thanks
Ruda
Re: [9fans] find command reloaded
search the archives for mails subjected as : breadth first walking and du and find from December 2009 On 22/01/2010 17:29, Rudolf Sykora wrote: Hello, I've been wondering. The plan9 'replacement' for the (linux/unix-like) find command, according to the faq, is, in a way,
Re: [9fans] find command reloaded
On Fri, Jan 22, 2010 at 5:29 PM, Rudolf Sykora rudolf.syk...@gmail.comwrote:
Hello,
I've been wondering.
The plan9 'replacement' for the (linux/unix-like) find command, according
to the faq, is, in a way,
grep foo `{du -a . | awk '{print $2}'}
Now I want to find all files containing foo.
Is it so that `{ ... } produces the full list first and only afterwards
this is used?
If so (and as I understand it really is so), the number of arguments may be
enormous, e.g. millions of names...
I don't feel this is the way to go...
How do you carry out such a search?
Thanks
Ruda
Have you come across a situation where it doesn't work or it's too slow for
your needs?
Robby
Re: [9fans] find command reloaded
2010/1/22 ron minnich rminn...@gmail.com I just do du -a . | grep foo Isn't it that this finds files whose filenames contain foo (like foofoo2.txt)?! I want files inside which there is foo somewhere... Thanks R
Re: [9fans] find command reloaded
2010/1/22 Robert Raschke rtrli...@googlemail.com Have you come across a situation where it doesn't work or it's too slow for your needs? Robby Well. I honestly don't know where the limits are. So generally, how long can the line be? My filesystem has now about 1e6 files, i.e. is of a modest size. Thus you need about 10 MB just for the list. Regardless of me having or not having encountered a problem, building the whole list in advance is not really smart and will lead to problems at some point for sure. Thanks R
Re: [9fans] find command reloaded
2010/1/22 maht maht-9f...@maht0x0r.net search the archives for mails subjected as : breadth first walking and du and find from December 2009 Ok, I will. I just thought there is a well-established way. R
Re: [9fans] find command reloaded
On 1/22/2010 12:59 PM, Rudolf Sykora wrote:
Regardless of me having or not having encountered a problem, building
the whole list in advance is not really smart and will lead to
problems at some point for sure.
Thanks
R
Assuming that's true, couldn't you do some kind of trick to break it up
(mind you my syntax may be wrong, I don't use plan9 often)
for(i in a b c [and so on]) grep foo `{du -a . | awk '{print $2}' | grep
^$i}
If you're worried about the argument list being too long that would
break it up into 26 separate greps with smaller arg lists I believe
Re: [9fans] find command reloaded
If looking through code: du -a . | xargs g pattern [2]/dev/null If looking through all files: du -a . | xargs grep -n foo [2]/dev/null The -n is to be friendly with acme. This presumes you have (at least a cheap knockoff of) xargs.
Re: [9fans] find command reloaded
Building a large list in advance can exhaust main memory on smaller terminals.
Re: [9fans] find command reloaded
I found your post a bit confusing then. The little bit of script you posted won't do the job, and the problem is not related to find at all, Anyway, while working with some hugely messy non-plan 9-software, I found I really needed grep -r. See /n/sources/contrib/rminnich/grep ron
Re: [9fans] find command reloaded
On Fri, Jan 22, 2010 at 01:08:02PM -0500, Corey Thomasson wrote:
On 1/22/2010 12:59 PM, Rudolf Sykora wrote:
Regardless of me having or not having encountered a problem,
building the whole list in advance is not really smart and will
lead to problems at some point for sure.
Thanks
R
Assuming that's true, couldn't you do some kind of trick to break it
up (mind you my syntax may be wrong, I don't use plan9 often)
for(i in a b c [and so on]) grep foo `{du -a . | awk '{print $2}' |
grep ^$i}
If you're worried about the argument list being too long that would
break it up into 26 separate greps with smaller arg lists I believe
In linux there is the xargs command, which will read lines from stdin
and distribute them in chunks to the arguments of another command, as in
du -a . | awk '{print $2}' | xargs -n 10 grep foo
This will take every 10 lines of stdin and append them to grep foo.
It's quite a useful command and seems to provide a unique function. Is
there some equivalent of this in Plan 9?
Also, the title of this thread is a bit misleading. As far as I know,
find doesn't have the option to test for the contents of files, so even
with find you'd have to use xargs and grep.
Re: [9fans] find command reloaded
I found your post a bit confusing then. The little bit of script you
posted won't do the job, and the problem is not related to find at
all,
Anyway, while working with some hugely messy non-plan 9-software, I
found I really needed grep -r.
See /n/sources/contrib/rminnich/grep
why not just use a russ' g from p9p?
- erik
here's a variant:
#!/bin/rc
rfork e
filepat='\.h$'
exec g $*
of my version:
#!/bin/rc
rfork e
flags=-n
re=()
files=/dev/null
f=1
if(~ $#filepat 0)
filepat = '\.[Cbchlmsy]$'
fn collect{
find $* | grep $filepat
}
fn collect1{
ls | grep $filepat
}
for(i){
if(~ $f 1 ~ $i -*)
flags = ($flags $i)
if not if (~ $#re 0){
f = 0
re = $i
}
if not{
if(test -d $i)
files = ($files `{collect $i})
if not
files = ($files $i)
}
}
if(~ $#re 0){
echo usage: g '[flags]' pattern ... [1=2]
exit usage
}
modre[2=]
switch($#files){
case 1
grep $flags $re `{collect1} $files
case *
grep $flags $re $files
}
Re: [9fans] find command reloaded
On Fri, Jan 22, 2010 at 10:19 AM, Joseph Xu joseph...@gmail.com wrote: Also, the title of this thread is a bit misleading. As far as I know, find doesn't have the option to test for the contents of files, so even with find you'd have to use xargs and grep. if you have find you don't need the xargs; -exec will do. ron
Re: [9fans] find command reloaded
2010/1/22 Joseph Xu joseph...@gmail.com
Also, the title of this thread is a bit misleading. As far as I know,
find doesn't have the option to test for the contents of files, so even
with find you'd have to use xargs and grep.
Let me explain then.
In Linux I'd use something like
find . -type f -exec grep -l foo {} \;
So, you are right about the need to use grep. On the other hand, the linux
find command takes care of the repetition...
R
Re: [9fans] find command reloaded
2010/1/22 ron minnich rminn...@gmail.com
I found your post a bit confusing then. The little bit of script you
posted won't do the job, and the problem is not related to find at
all
The relation to the find command: the linux/unix find command can be
producing and using the list at the same time (actually it perhaps doesn't
even create any list).
Why do you think
grep foo `{du -a . | awk '{print $2}'}
doesn't do the job? Apart from potentially reporting one file several
times...
Thanks
R
Re: [9fans] find command reloaded
now I understand your question.
I just tested this and it worked fine.
du -a / | awk '{print grep something $2}' |/bin/rc
ron
Re: [9fans] find command reloaded
On Fri, Jan 22, 2010 at 10:40 AM, Rudolf Sykora rudolf.syk...@gmail.com wrote:
Why do you think
grep foo `{du -a . | awk '{print $2}'}
doesn't do the job? Apart from potentially reporting one file several
times...
Because my brain is only partially on today!
ron
Re: [9fans] find command reloaded
These two scripts should be enough to do what's needed:
; cat /bin/xargs
#!/bin/rc
# xargs cmd [arg ...] - emulate Unix xargs
# only needed for arg lists longer than TSTKSIZ*BY2PG
# (100*4096 = 400K on typical PC kernels).
rfork ne
ramfs
split -n 500 -f /tmp/x
for (f in /tmp/x*)
$* `{cat $f}
; cat /bin/files
#!/bin/rc
# files [dir...] - enumerate files below dir(s)
du -a $* | sed 's/^[^]+[ ]+//' | sort -u
Can we stop now?
Re: [9fans] find command reloaded
why not just use a russ' g from p9p? Ok. Maybe. So now I have several propositions: - g by R Cox - sth similar to g by E Quanstrom - grep -r by R Minnich (actually, this really exists in linux, I didn't know...) - search the archives for mails subjected as : breadth first walking, du and find, from December 2009, by maht - get sth like xargs somewhere, e.g. by J Catena Can anybody comment on these and their differences? I don't know 'g' yet. I'll look at it shortly. Anyway, it seems to me that something like xargs could be of quite general use, so probably also be a better solution than anything like 'grep -r' (adding switches to individual commands to do some job recursively). Thanks R
Re: [9fans] find command reloaded
On unix systems I tend to use find a lot, and in ways that aren't easy to replicate with du. Anything even slightly complicated, say combining -prune, -type, -newer, and -exec, is nearly impossible to do in a correct and efficient way without find, even if you have an xargs. I'm not sure I understand the resistance to having a find command in plan9. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] find command reloaded
I just tested this and it worked fine.
du -a / | awk '{print grep something $2}' |/bin/rc
ron
Try
touch 'x;reboot'
and then see if it still works fine. I don't think I like your
version on a system with users I don't trust completely.
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282
Re: [9fans] find command reloaded
du -a / | awk '{print grep something $2}' |/bin/rc
ron
Try
touch 'x;reboot'
and then see if it still works fine. I don't think I like your
version on a system with users I don't trust completely.
sneaky. but it won't work.
; touch 'x;reboot'
; du -a .
0 './x;reboot'
0 .
- erik
Re: [9fans] find command reloaded
Recursively list only files; grep them with g to get full path, filename, and line number; protect against John's semicolon trick by quoting each file. walk -f | sed 's,^,g '^$1^' '',;s,$,'',' | rc walk apparently completely omits from its output files with a single-quote in their names, and does not quote files with embedded semicolons. ls lists them both quoted, with the embedded single-quote doubled. All this tested in p9p.
Re: [9fans] find command reloaded
sneaky. but it won't work. ; touch 'x;reboot' ; du -a . 0 './x;reboot' 0 . - erik It worked under 9vx on my Mac. I didn't test on real hardware. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] find command reloaded
On Fri Jan 22 15:24:49 EST 2010, stal...@maths.tcd.ie wrote:
sneaky. but it won't work.
; touch 'x;reboot'
; du -a .
0 './x;reboot'
0 .
- erik
It worked under 9vx on my Mac. I didn't test on real hardware.
this rebooted your 9vx? sounds wrong to me.
i thought the orginal script was
du -a . | awk '{print grep -l pattern $2}' | rc
if i run that on my machine, i get
; du -a . | awk '{print grep -l something $2}'
grep -l something './x;reboot'
grep -l something .
if executed, that won't reboot your machine.
it will just print x;reboot. if you were to reexecute
that, it would. but you wouldn't want to execute a list
of file names, would you?
- erik
Re: [9fans] find command reloaded
On Fri, Jan 22, 2010 at 12:16 PM, Jason Catena jason.cat...@gmail.com wrote: Recursively list only files; grep them with g to get full path, filename, and line number; protect against John's semicolon trick by quoting each file. john's semicolon trick is fun but as pointed out doesn't work. ron
Re: [9fans] find command reloaded
On Fri, Jan 22, 2010 at 12:23 PM, John Stalker stal...@maths.tcd.ie wrote: sneaky. but it won't work. ; touch 'x;reboot' ; du -a . 0 './x;reboot' 0 . - erik It worked under 9vx on my Mac. I didn't test on real hardware. interesting. OK, my idea sucks due to a lack of foresight on my part :-) So far, given the complexity of all the alternatives, I'm sticking with my grep -r. Yeah, it's gross to special-case something, but sometimes a special case has more use than a general case. But, hey, if you don't like my idea don't use it. No feelings will be harmed; after all, I've only got one real user for smacme and it's not me :-) And if you like find, write and put it in contrib. I don't understand all the concern about whether this or that tool ends up in the official tree, or who is resistant to it. Plan 9 is a distributed OS. Roll your own tree. put it on bitbucket. Add all the stuff you think should be there. Maybe others will like it too. In the 70s just about every university had a Unix distro ... harvard, jhu, on and on ... it was only in the 80s that BSD became the choice item. With the tools we have today it's pretty easy to fork something. Who knows, you might pull a BSD :-) ron
Re: [9fans] find command reloaded
this rebooted your 9vx? sounds wrong to me. It did, or rather it tried to. Of course, /bin/reboot doesn't work in 9vx. I tested it before I posted. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] find command reloaded
the only time I ever wanted this kind of feature is for grepping through sourcecode. ron's modified grep is now installed on my boxes; there is a precident (diff -r). -Steve
Re: [9fans] find command reloaded
interesting. OK, my idea sucks due to a lack of foresight on my part :-) Your idea is fine. I do similar things all the time, but using awk or sed or things like that to produce shell scripts is hard to get right. Harder than getting a find command right, which was my point. I'll grant that life is easier if the shell you're piping to is /bin/rc than /bin/sh. So far, given the complexity of all the alternatives, I'm sticking with my grep -r. Yeah, it's gross to special-case something, but sometimes a special case has more use than a general case. That's fine for Rudolf's situation, but most of my find commands end in -delete. But, hey, if you don't like my idea don't use it. No feelings will be harmed; after all, I've only got one real user for smacme and it's not me :-) I actually like your idea better than any of the others that were suggested except for the idea of a native version of find. And if you like find, write and put it in contrib. I'll put it on my to do list. But things often stay on that list for a long time. :-( I don't understand all the concern about whether this or that tool ends up in the official tree, or who is resistant to it. Plan 9 is a distributed OS. Roll your own tree. put it on bitbucket. Add all the stuff you think should be there. Maybe others will like it too. In the 70s just about every university had a Unix distro ... harvard, jhu, on and on ... it was only in the 80s that BSD became the choice item. With the tools we have today it's pretty easy to fork something. Who knows, you might pull a BSD :-) We had one here at TCD, though that was well before my time. These days all the servers run FreeBSD. Although I like plan9, I don't think it's likely to get installed on those servers any time soon. ron -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] find command reloaded
the only time I ever wanted this kind of feature
is for grepping through sourcecode.
ron's modified grep is now installed on my boxes;
there is a precident (diff -r).
If you're like me, you often have a bunch of object files
in your source tree and you usually want to enumerate
files, filter out some of the names and then grep the resulting
list... ie. recursive grep will grep a bunch of files you
dont want to grep... something like:
grep -n foo `{f|grep '\.c'}
will go much faster (assuming /bin/f enumerates filenames).
-Steve
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
[9fans] 9p question: rationale for some missing POSIX-like operations and features
Hy there! (I'm quite new to the whole Plan 9 and 9P, so please bare with me if I'm asking stupid or well known questions.) :) Today I've introduced myself to the 9P protocol, and I've found it very interesting. (I've reached it from the XCPU project.) (And I must say that, in Linux, it could replace FUSE (File System in User Space) for most use-cases.) But after I've read (actually more skimmed through) the documentation (man pages from 9p.cat-v.org) I've asked myself the following questions and I thought that maybe the people on this mailing list could help me better understand the problem / answers. A) Why aren't there the following (POSIX) file operations: `move`, `link` and `symlink` in the original 9p2000 protocol version? Now I know that by using `wstat` I can change the name of a file, but I can't move it outside the current directory. I'm would say that all these three operations could be done by using the 9p2000.u protocol extension to create. (For example a new DMLINK type could be created that could act just like DMSYMLINK, but create a hard-link instead, and in this way a move operation would be just an link, then unlink operation, but by losing the atomicity which could be required in certain contexts.) (By the way, why isn't there such a DMLINK option for the extended `create` operation?) B) Also why isn't there a way to do meta-operations on files? For example: application specific requests on file-id's? Something like: size[4] Tquery tag[2] fid[4] int[4](query-request-selector) input[s] size[4] Rquery tag[2] fid[4] int[4](query-response-selector) output[s] This would allow to implement things like ioctl's, or extended attributes. Even more, someone could easily map HTTP requests over the 9p protocol, by asserting that after opening the file (which is the path part of the URL), one should immediately call query to set headers, then do a write (for the body), then do query (to obtain the response headers), and then do read (for the response body). (Of course another way to do this is to just write to the file headers plus body just like in a normal HTTP stream, but this would imply special parsing on the server side. Meanwhile with my solution, the server will just ignore the query requests.) Also I'm aware of the fact that I could (in theory) attach to a different `aname`, one that would be the meta-tree of the actual tree. And in here each file / directory in the real tree would have a corresponding directory / sub-files that would allow me to do meta-operations on the file-system. (Like moving, would be achieved by writing a qid structure to a file named 'link' in the directory corresponding to the real-directory, and then calling `remove` on the real-tree. (Or something similar to this.)) But this solution (as possible as it could be) it's cumbersome. C) If I open a file for both reading and writing, why isn't there a way to `clunk` (after some time) just the input part, or just the output part? (Again would be usable in the case of the HTTP mapping, when I don't know how much data the client is going to write as part of the request body.) Thank you all for your time, Ciprian.
Re: [9fans] find command reloaded
And if you like find, write and put it in contrib. contrib/pull quanstro/find - erik
Re: [9fans] 9p question: rationale for some missing POSIX-like operations and features
A) Why aren't there the following (POSIX) file operations: `move`, `link` and `symlink` in the original 9p2000 protocol version? Now I know that by using `wstat` I can change the name of a file, but I can't move it outside the current directory. symlinks weren't wanted. they create many problems and can be simulated with bind(1). link similarly was not wanted. it assumes too much about the structure of the filesystem. move across directories is not supported because they may be on different file servers. B) Also why isn't there a way to do meta-operations on files? For example: application specific requests on file-id's? Something like: size[4] Tquery tag[2] fid[4] int[4](query-request-selector) input[s] size[4] Rquery tag[2] fid[4] int[4](query-response-selector) output[s] this is done with [TR]write. for example, to do a dns query you write the query into /net/dns and read the response from the same fd. - erik
Re: [9fans] find command reloaded
And if you like find, write and put it in contrib. contrib/pull quanstro/find - erik Thanks -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] 9p question: rationale for some missing POSIX-like operations and features
There's a nice paper The use of namespaces in plan 9 explaining most of it. On Fri, Jan 22, 2010 at 11:00 PM, erik quanstrom quans...@coraid.com wrote: A) Why aren't there the following (POSIX) file operations: `move`, `link` and `symlink` in the original 9p2000 protocol version? Now I know that by using `wstat` I can change the name of a file, but I can't move it outside the current directory. symlinks weren't wanted. they create many problems and can be simulated with bind(1). link similarly was not wanted. it assumes too much about the structure of the filesystem. move across directories is not supported because they may be on different file servers. B) Also why isn't there a way to do meta-operations on files? For example: application specific requests on file-id's? Something like: size[4] Tquery tag[2] fid[4] int[4](query-request-selector) input[s] size[4] Rquery tag[2] fid[4] int[4](query-response-selector) output[s] this is done with [TR]write. for example, to do a dns query you write the query into /net/dns and read the response from the same fd. - erik
Re: [9fans] Now with authentication
Hi Newsham, Is OpenSSL necessary for authenticating to 9P servers? Currently, I get a failed to mount ...: 22 botch error when trying to authenticate. Also, is it necessary to compile ninefs with OpenSSL, or will the pre-compiled binary find and use c:\openssl if it's there? Thanks, ak On Thu, Jan 21, 2010 at 1:50 PM, Tim Newsham tim.news...@gmail.com wrote: The Jan5 binaries were broken, thanks for those who reported the problem. I've uploaded new binaries and updated the README to include instructions on installing OpenSSL binaries. On Jan 5, 10:16 am, Tim Newsham tim.news...@gmail.com wrote: I added p9sk1/p9any authentication support to npfs and added support for authentication to ninefs. The README has been updated with new build instructions (OpenSSL is now a dependency) and an updated binary has been put in the downloads area.
Re: [9fans] mysterious auth
in case anyone's wondering, my problem was due to the fact that keyfs was started after aux/listen for trusted services; /mnt/keys/* wasn't in authsrv's namespace. in my case, i put the trusted services in /cfg/bootes/cpurc, while keyfs was started later in the sequence of /rc/bin/cpurc. the default config in the distro CD could lead others to do the same. given that only auth needs to run keyfs and trusted services, it would be better to create a /cfg/example.auth/cpurc that includes keyfs and trusted services in it and remove them from /rc/bin/cpurc, since they come after /cfg/$sysname/cpurc is run. are you sure that the passwords in nvram and auth/changeuser do match for bootes? pretty sure. i've zero'ed the nvram and re-entered it. i went so far as stopping keyfs, zero'ing /adm/keys and /adm/keys.who and reinstalling bootes from scratch and restarting. it is very puzzling. Lucio said: Should you not add a role=server to whatever the chosen entry is? It will at minimum help with debugging. i did, but the result changed only slightly; trying to connect to auth from another system now results in the same behavior as auth/debug exhibits: no key matches.
Re: [9fans] Now with authentication
The OpenSSL DLL is necessary to run the executable. Off hand I couldnt tell you why you got the botch message. If you could provide more details on what traffic you see, or a way to reproduce, I can look into it. You just need to have the proper openssl DLL in your path. The windows installer copies it into your windows system32 directory. You don't really need the rest of the stuff that it puts into c:\openssl, so it doesnt matter where you have it. On Fri, Jan 22, 2010 at 12:51 PM, Akshat Kumar aku...@mail.nanosouffle.netwrote: Hi Newsham, Is OpenSSL necessary for authenticating to 9P servers? Currently, I get a failed to mount ...: 22 botch error when trying to authenticate. Also, is it necessary to compile ninefs with OpenSSL, or will the pre-compiled binary find and use c:\openssl if it's there? Thanks, ak On Thu, Jan 21, 2010 at 1:50 PM, Tim Newsham tim.news...@gmail.com wrote: The Jan5 binaries were broken, thanks for those who reported the problem. I've uploaded new binaries and updated the README to include instructions on installing OpenSSL binaries. On Jan 5, 10:16 am, Tim Newsham tim.news...@gmail.com wrote: I added p9sk1/p9any authentication support to npfs and added support for authentication to ninefs. The README has been updated with new build instructions (OpenSSL is now a dependency) and an updated binary has been put in the downloads area. -- Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
Re: [9fans] mysterious auth
On Fri Jan 22 18:29:45 EST 2010, 9...@9netics.com wrote: in case anyone's wondering, my problem was due to the fact that keyfs was started after aux/listen for trusted services; /mnt/keys/* wasn't in authsrv's namespace. in my case, i put the trusted services in /cfg/bootes/cpurc, while keyfs was started later in the sequence of /rc/bin/cpurc. the default config in the distro CD could lead others to do the same. given that only auth needs to run keyfs and trusted services, it would be better to create a /cfg/example.auth/cpurc that includes keyfs and trusted services in it and remove them from /rc/bin/cpurc, since they come after /cfg/$sysname/cpurc is run. i was wondering. thanks for the explaination. - erik
Re: [9fans] find command reloaded
And if you like find, write and put it in contrib. contrib/pull quanstro/find - erik Thanks -- John Stalker Does this answer Ron's question as to why one wants things added to the distribution, not just tacked onto any old branched version? ++L
Re: [9fans] mysterious auth
it would be better to create a /cfg/example.auth/cpurc that includes keyfs and trusted services in it and remove them from /rc/bin/cpurc, since they come after /cfg/$sysname/cpurc is run. You could submit a patch... I have a feeling that the philosophy is for /cfg to be entirely optional, so putting examples in there is not encouraged. But what about (late in /rc/bin/cpurc): # cpu-specific late startup if(test -e /cfg/$sysname/cpustart) . /cfg/$sysname/cpustart ? ++L
