Re: [9fans] fOSSa
I think my wrists seized up just thinking about programming in XML. Don't worry; that's just a natural RefleX. Ha-ha...
Re: [9fans] kw audio -- /dev/audio and friends
2010/10/28 Anthony Sorace a...@9srv.net: the other problem with both volume and audioctl will come with multiple streams. in1 and out1 might work, but it starts to look ugly. usbaudio appears to ignore multiple inputs or outputs. i'm not entirely sure what you mean by streams in this context. multiple inputs or outputs? if so, my first pass would be do something like what #l does: #l0, #l1, c. Alternately, let any (theoretical future) driver for such a thing implement /mnt/fancydriver/0/audio c, and bind as needed. Wouldn't it be better to use #A0, #A1, ... for the case of multiple audio devices instead of multiple in/outs in one device? I don't see why control^(1 2 3 4 5 6) or in1, out1 are so ugly (specially considering that this is just a potential problem). -- - yiyus || JGL . 4l77.com
Re: [9fans] A little more ado about async Tclunk
you're essentially replacing f := open(name, ...) ... close(f) which runs as a sequential process, and subject to the usual rules for sequential composition, by f := open(name, ...) ... spawn clunk(f) which introduces a race with an invisible anonymous process with no means of synchronisation. what could possibly go wrong with that? (actually, it's more complex than spawning a new process, but the added complexity of a set of service processes changes the details but not the existence of the race, and doesn't affect the anonymity.) the change isn't sufficent to solve the efficiency (latency) problems addressed by Op, neither is it sufficient for big performance improvements if you're dealing with something you can cache, nor is it a necessary solution (at least in the form above) for the deadlock problems.
Re: [9fans] kw audio -- /dev/audio and friends
multiple inputs or outputs? if so, my first pass would be do something like what #l does: #l0, #l1, c. Wouldn't it be better to use #A0, #A1, ... for the case of multiple audio devices instead of multiple in/outs in one device? that would make sense to me, though if there's a ethernet card that had multiple interfaces in an analogous way, #l0, #l1 would probably be used. I don't see why control^(1 2 3 4 5 6) or in1, out1 are so ugly (specially considering that this is just a potential problem). the cs42l51 (the codec used on the openrd) audioctl looks like this: power in 1 0 1 pgapower in 1 0 1 boost in 0 0 1 micdiff in 0 0 1 micbias in 0 0 3 1 micboost0 in 0 0 1 micboost1 in 0 0 1 gain0 in 0 -6 24 1 gain1 in 0 -6 24 1 atten0 in 0 -96 0 1 atten1 in 0 -96 0 1 vol0 in 0 -103 24 1 vol1 in 0 -103 24 1 mute0 in 0 0 1 mute1 in 0 0 1 power out 1 0 1 hpgain out 3 0 7 1 vol0 out 0 -103 24 1 vol1 out 0 -103 24 1 mute0 out 0 0 1 mute1 out 0 0 1 treble out 0 -21 24 1 bass out 0 -21 24 1 volume0 out 0 -204 12 1 volume1 out 0 -204 12 1 mix0 out 0 0 3 mix1 out 0 0 3 with my current incarnation that becomes: audictl: power 0 1 1 pgapower 0 1 1 boost 0 1 0 micdiff 0 1 0 micbias 0 1 0 micboost 0 1 0 0 gain -6 24 0 0 atten -96 0 0 0 vol -103 24 0 0 mute 0 1 0 0 audoctl: power 0 1 1 hpgain 0 7 3 vol -103 24 0 0 mute 0 1 0 0 treble -21 24 0 bass -21 24 0 volume -204 12 0 0 mix 0 3 0 0 to me, that is ugly, without in1 and out1. ugly enough to talk about change, maybe not ugly enough to change. volume is fairly nice: (except with percentages of the range) power in 1 out 1 pgapower in 1 boost in 0 micdiff in 0 micbias in 0 micboost in 0 0 hpgain out 3 gain in 0 0 atten in 0 0 vol in 0 0 out 0 0 mute in 0 0 out 0 0 treble out 0 bass out 0 volume out 0 0 mix out 0 0 and easially extendable: vol in 0 0 0 0 0 0 out 0 0 0 0 0 0 out1 0 0 0 0 0 0 but it doesn't give the ranges. ? vol -103 24 in 0 0 out 0 0 which looks liable to break things (out being optional). tristan (with apologies for such a long post) -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] A little more ado about async Tclunk
no it is not, charles. i rarely disagree with you but the semantics are preserved, except for changing the behaviour of existing races. brucee On Thu, Oct 28, 2010 at 11:12 PM, Charles Forsyth fors...@terzarima.net wrote: you're essentially replacing f := open(name, ...) ... close(f) which runs as a sequential process, and subject to the usual rules for sequential composition, by f := open(name, ...) ... spawn clunk(f) which introduces a race with an invisible anonymous process with no means of synchronisation. what could possibly go wrong with that? (actually, it's more complex than spawning a new process, but the added complexity of a set of service processes changes the details but not the existence of the race, and doesn't affect the anonymity.) the change isn't sufficent to solve the efficiency (latency) problems addressed by Op, neither is it sufficient for big performance improvements if you're dealing with something you can cache, nor is it a necessary solution (at least in the form above) for the deadlock problems.
[9fans] crashing 9vx
I keep hearing how 9vx is very unstable and have a lot of problems, but after a few months working on it I have not received many bug reports. Probably I won't know how to fix these problems, but at least I'd like to have them documented. Also, I'm updating the autogenerated kernel files and would like to check if this makes any difference. So, if you are using the 9vx version at http://bitbucket.org/yiyus/vx32/ (or ron's version, which is almost the same) and you have a reproducible way to crash it, could you please fill an issue in bitbucket or send me an email? Thanks. -- - yiyus || JGL . 4l77.com
Re: [9fans] A little more ado about async Tclunk
On Thu, Oct 28, 2010 at 2:12 PM, Charles Forsyth fors...@terzarima.net wrote: you're essentially replacing f := open(name, ...) ... close(f) which runs as a sequential process, and subject to the usual rules for sequential composition, by f := open(name, ...) ... spawn clunk(f) which introduces a race with an invisible anonymous process with no means of synchronisation. Wouldn´t a better way be?: f := open(name, ...) tclunk(f); spawn deallocfid(f); //and whatever needs to be done on Rclunk Hmm, it would be more like sending the Tclunk and not waiting for the response. That would mean that the fid cannot be unmarked for reuse until the response is received (asynchronously), so it can be moved to a stale fid table to be deallocated later. Most of the semantics are the same. I agree that the performance gain is probably not enough to bother anyway. You are still doing all the walks and so on. Unless clunk means something in slang :-P. G.
Re: [9fans] A little more ado about async Tclunk
Wouldn´t a better way be?: f := open(name, ...) tclunk(f); spawn deallocfid(f); //and whatever needs to be done on Rclunk Hmm, it would be more like sending the Tclunk and not waiting for the response. That would mean that the fid cannot be unmarked for reuse until the response is received (asynchronously), so it can be moved to a stale fid table to be deallocated later. Most of the semantics are the same. Assuming messages are not reordered. -- - curiosity sKilled the cat
Re: [9fans] A little more ado about async Tclunk
One problem I have with delayed clunks is that when you have caches or the like, close might fail. Not an issue on Inferno, but, I'd still like to be able to get back in sync at close time if only to be able to check that everything's ok and safe in the server. On Thu, Oct 28, 2010 at 4:30 PM, Gorka Guardiola pau...@gmail.com wrote: On Thu, Oct 28, 2010 at 2:12 PM, Charles Forsyth fors...@terzarima.net wrote: you're essentially replacing f := open(name, ...) ... close(f) which runs as a sequential process, and subject to the usual rules for sequential composition, by f := open(name, ...) ... spawn clunk(f) which introduces a race with an invisible anonymous process with no means of synchronisation. Wouldn´t a better way be?: f := open(name, ...) tclunk(f); spawn deallocfid(f); //and whatever needs to be done on Rclunk Hmm, it would be more like sending the Tclunk and not waiting for the response. That would mean that the fid cannot be unmarked for reuse until the response is received (asynchronously), so it can be moved to a stale fid table to be deallocated later. Most of the semantics are the same. I agree that the performance gain is probably not enough to bother anyway. You are still doing all the walks and so on. Unless clunk means something in slang :-P. G.
Re: [9fans] crashing 9vx
On Thu, Oct 28, 2010 at 04:00:32PM +0200, yy wrote: So, if you are using the 9vx version at http://bitbucket.org/yiyus/vx32/ (or ron's version, which is almost the same) and you have a reproducible way to crash it, could you please fill an issue in bitbucket or send me an email? Thanks. I only use 9vx as proof of concept and I have only two reportable issues: I can't get cpu to work where drawterm seems to succeed and on one occasion I used DEL to terminate a task and the whole of 9vx shut down. The latter is a little scary, but I have been very reluctant to test it :-) The cpu doesn't succeed seems to mean that I can't persuade it to use the target host as auth server. I could just be showing my ignorance and/or stupidity. ++L
Re: [9fans] A little more ado about async Tclunk
On Thu, Oct 28, 2010 at 9:41 AM, Francisco J Ballesteros n...@lsub.org wrote: One problem I have with delayed clunks is that when you have caches or the like, close might fail. Not an issue on Inferno, but, I'd still like to be able to get back in sync at close time if only to be able to check that everything's ok and safe in the server. Is that an argument for having the cache layer provide the service for you? Apps that care about end-to-end semantics aren't likely to be going through the cache layer anyways. Do we need differentiation between I don't care clunks and I care clunks? What's the actual spread of these in applications? Am I oversimplifying? That's quite possible. -eric
Re: [9fans] A little more ado about async Tclunk
Assuming messages are not reordered. ah, the easy problems can be taken care of by using 1 clunker and a clunk channel with a fixed buffer. i'd like to know more about charles' correctness concerns. not that this particular example is all that useful. cf. nemo My argument is that I'd like the operation to be able to fail in general, and to be synchronous, so I could get an error status (despite caches being placed in the middle). - erik
Re: [9fans] A little more ado about async Tclunk
On Thu, Oct 28, 2010 at 04:56:02PM +0200, Francisco J Ballesteros wrote: Be there caches of not, I've found that I want to be able to say I'm done with this file, let me know if everything is done and ok. You can, just not by using Tclunk. Of course, if you use 9p with no cache, you know you're done if all writes worked. Nowhere in the manual does it say that. The only protocol-defined way to be sure that you are coherent is to use Twstat with all arguments NOP. (FWIW, this may also be superior to checking that Tclunk did not Rerror because the fid is still live if Twstat Rerrors.) --nwf; pgp8F7o4gIlUa.pgp Description: PGP signature
Re: [9fans] A little more ado about async Tclunk
Nowhere in the manual does it say that. The only protocol-defined way to be sure that you are coherent is to use Twstat with all arguments NOP. (FWIW, this may also be superior to checking that Tclunk did not Rerror because the fid is still live if Twstat Rerrors.) name 3 in-distribution fileservers that respect this tradition uniformly. - erik
Re: [9fans] A little more ado about async Tclunk
Yes, in general, agree, but this was about clunk usage and semantics, and I think it's important to have the I'm done message synchronous when you need that. Btw, I think you mean Tstat, don't you? I'm not sure Twstat would work that way in practice.
[9fans] slides and troff
Hello, I'm using Uriel's macros for creating slides with groff (I'm unable to make p9p's troff to work). The slides look fine, but I can't add slide numbers at the bottom of each slide (which I expected to get, since the slide macros seem to modify the ms macro). I've been messing around with troff code, trying to get the slide numbering, but no results so far (I can't get the footer example from Osanna's user manual to work, given my inexperience with troff coding). Any help is appreciated. -- Hugo
Re: [9fans] slides and troff
I have used the foils package on plan9 and on osx in the past. /n/sources/contrib/steve/foils.tgz or http://plan9.bell-labs.com/sources/contrib/steve/foils.tgz -Steve
Re: [9fans] A little more ado about async Tclunk
On Thu, Oct 28, 2010 at 11:53 AM, Francisco J Ballesteros n...@lsub.orgwrote: Yes, in general, agree, but this was about clunk usage and semantics, and I think it's important to have the I'm done message synchronous when you need that. Btw, I think you mean Tstat, don't you? I'm not sure Twstat would work that way in practice. No, that was actually Twstat. -- vs
Re: [9fans] A little more ado about async Tclunk
On Thu, Oct 28, 2010 at 8:12 AM, Charles Forsyth fors...@terzarima.netwrote: you're essentially replacing f := open(name, ...) ... close(f) which runs as a sequential process, and subject to the usual rules for sequential composition, by f := open(name, ...) ... spawn clunk(f) which introduces a race with an invisible anonymous process with no means of synchronisation. what could possibly go wrong with that? (actually, it's more complex than spawning a new process, but the added complexity of a set of service processes changes the details but not the existence of the race, and doesn't affect the anonymity.) Hmm, I don't see the race there; perhaps I'm missing something or being blind; could you explain? Also, if that is racy, isn't this at least analogous? f := Sys-open(name, ...); ... # put f in a cyclic structure f = nil; evil_cyclic = nil; ... # wait until an invisible service process closes it, perhaps later? Thanks, -- vs
Re: [9fans] A little more ado about async Tclunk
Also, if that is racy, isn't this at least analogous? i don't think so: that instance is entirely at the discretion of the programmer. it would be analogous if the text of the program actually contained `spawn clunk(f)', but i was trying to represent the effects of the rewriting the system would be doing, and that rewriting (as it has been presented) is built in to the system call. the race is that there's nothing to say that the clunk completes before the process continues on to do something more, including some action that depends on the clunk completing, such as simply repeating the open. that open can fail if the mode or the name imposes particular constraints; constraints that depend on the order of events as expressed by the process. months ago, i did test an example on the system that just works, by the way, and it did fail. it often takes a few attempts for it to fail, because it depends on scheduling (often the system completes the clunk before returning to the original process), but there's nothing to stop it failing immediately.
Re: [9fans] A little more ado about async Tclunk
On Thu, Oct 28, 2010 at 4:18 PM, Charles Forsyth fors...@terzarima.netwrote: the race is that there's nothing to say that the clunk completes before the process continues on to do something more, including some action that depends on the clunk completing, such as simply repeating the open. that open can fail if the mode or the name imposes particular constraints; constraints that depend on the order of events as expressed by the process. Of course, we don't want the process to wait. On a 'decent' file server, TClunk doesn't do anything that a process would have to wait for, except invalidate the FID; (I exclude ORCLOSE and OEXCL files here). Guarding this with MCACHE means that there was already a statement from the user I think that this file server is a decent character.. You can definitely write file servers on which TClunk does things -- ones in which the right combination of opens and clunks fires the missiles, for example. This is not for those file servers. On a decent server, since clunk cannot fail and won't launch the missiles, you can't really do anything that would depend on the result anyway... Seem reasonable? -- vs
Re: [9fans] A little more ado about async Tclunk
On Thu, Oct 28, 2010 at 4:55 PM, Nemo nemo.m...@gmail.com wrote: i have decent servers that wait for clunk to operate on written data once it's complete. all octopus spoolers do that. Heh; when I wrote 'decent', I was recalling the old proposed QTDECENT qid type. I didn't mean to impugn your file servers; they're probably very nice people and if I met them, I'd should buy them a drink. Let's try to define 'decent' for this thread -- a decent fileserver is one on which close()s do not have any client-visible or semantic effect other than to invalidate the Fid that was passed to them. Lets see how many file servers we can think of that are 'decent': fossil, kfs, ken, memfs, ... -- vs
Re: [9fans] A little more ado about async Tclunk
months ago, i did test an example on the system that just works, by the way, and it did fail. it often takes a few attempts for it to fail, because it depends on scheduling (often the system completes the clunk before returning to the original process), but there's nothing to stop it failing immediately. :-) had a bit of hardware with a race that mostly worked. mean time to failure for a single unit was ~40 days. unfortunately, there wasn't just one, there were 1000. - erik
[9fans] ndb database checker: ndb/vrfy
a number of weeks ago, to facilitate migrating many hundreds of machines to a new network setup, i wrote a simple and fairly bone-headed ndb database checker, ndb/vrfy. it was amazingly effective, if provincial. it catches all the classics like badly formatted eas, duplicate eas, mistyped keys (eg ethr and not ether) the referenced, but not included, checkndb, checks to see that the user was okay (not expired, in ndb), but depends on local rules, kenfs and /adm/keystat, none of which are universal. /adm/keystat is a local invention to allow anyone to make a rough check for expired keys. if you really want a copy email me privately. - erikfrom postmas...@plug: The following attachment had content that we can't prove to be harmless. To avoid possible automatic execution, we changed the content headers. The original header was: Content-Type: text/troff Content-Disposition: attachment; filename=ndbvrfy Content-Transfer-Encoding: base64 ndbvrfy.suspect Description: Binary data
Re: [9fans] A little more ado about async Tclunk
On Thu, Oct 28, 2010 at 10:18 PM, Charles Forsyth fors...@terzarima.net wrote: the race is that there's nothing to say that the clunk completes before the process continues on to do something more, including some action that depends on the clunk completing, such as simply repeating the open. that open can fail if the mode or the name imposes particular constraints; constraints that depend on the order of events as expressed by the process. What you are saying is that the problem could be something like: - Tclunk (do not wait for response) - Topen (the file is exclusive) Then somehow in the server, Tclunk and Topen are reordered because they are managed by different threads and Topen gets an error because the file is already opened. This is a problem, I agree. On Oct 28, 2010, at 10:32 PM, Venkatesh Srinivas m...@acm.jhu.edu wrote: On a decent server, since clunk cannot fail and won't launch the missiles, you can't really do anything that would depend on the result anyway. Tclunk may be a good time to commit to disk or do other unmissile like thing. You can switch to another cache after waiting for the Rclunk, for example. Decent or not indecent I am more and more conviced after this thread that Tclunk should be synchronous. Even in decent files Tclunk can have some side effects.
Re: [9fans] ndb database checker: ndb/vrfy
i have no idea why the yacc source wasn't included.
here it is.
- erik%{
#include u.h
#include libc.h
#include bio.h
#include ip.h
typedef struct T T;
struct T{
T *next;
T *down;
char*s;
char*t;
int line;
char*file;
};
#pragma varargcktypeT T*
Biobuf in;
char*file;
char*ipmask;
int line;
int factotum;
T *dblist;
T *ll0;
T **ll;
T *tab0;
T **tab;
int fd;
extern int yyparse(void);
extern voidyyerror(char*, ...);
char*
nonil(char *s)
{
if(s == nil)
return ;
return s;
}
int
Tfmt(Fmt *f)
{
int sharp;
T *t, *t0;
t0 = va_arg(f-args, T*);
sharp = f-flags FmtSharp;
for(; t0 != nil; t0 = t0-down){
if((t = t0) != nil)
fmtprint(f, %s=%s, t-s, nonil(t-t));
while(t = t-next)
fmtprint(f, %s=%s, t-s, nonil(t-t));
if(sharp == 0)
break;
if(t0-down != nil)
fmtprint(f, \n);
}
return 0;
}
T*
newt(char *s, char *t)
{
T *x;
x = malloc(sizeof *x);
if(x == nil)
sysfatal(malloc: %r);
memset(x, 0, sizeof *x);
x-s = s;
x-t = t;
x-line = line;
x-file = file;
return x;
}
static char *nakedtab[] = {
database,
soa,
trampok,
};
int
cknaked(char *s)
{
int i;
for(i = 0; i nelem(nakedtab); i++)
if(strcmp(nakedtab[i], s) == 0)
return 0;
yyerror(naked token %s, s);
return -1;
}
%}
%union{
T *t;
char*s;
}
%type s rhs
%token s S
%start db
%%
db :
| db '\n'
| db tuples '\n'
;
tuples: tuple {
*tab = ll0;
tab = ll0-down;
ll0 = nil;
ll = ll0;
}
| tuple tuples
;
tuple: S rhs {
T *x;
if($2 == nil)
cknaked($1);
x = *ll = newt($1, $2);
ll = x-next;
}
;
rhs:{ $$ = nil; }
| '=' S { $$ = $2; }
;
%%
void
freet(T *t)
{
T *n, *d;
for(; t != nil; t = d){
d = t-down;
for(; t != nil; t = n){
n = t-next;
free(t-s);
free(t-t);
free(t);
}
}
}
void
yyinit(char *f)
{
file = f;
line = 1;
fd = open(file, OREAD);
if(fd == -1)
sysfatal(open: %r);
if(Binit(in, fd, OREAD) == -1)
sysfatal(Binit: %r);
freet(tab0);
ll0 = nil;
tab0 = nil;
ll = ll0;
tab = tab0;
}
void
yyerror(char *fmt, ...)
{
char buf[256], *p, *e;
va_list arg;
static int nerrors;
e = buf + sizeof buf;
va_start(arg, fmt);
p = seprint(buf, e, %s:%d , file, line);
p = vseprint(p, e, fmt, arg);
p = seprint(p, e, \n);
va_end(arg);
write(2, buf, p - buf);
nerrors++;
if(nerrors 5)
sysfatal(too many errors);
}
void
tokerror(T *t, char *fmt, ...)
{
char buf[256], *p, *e;
va_list arg;
static int nerrors;
e = buf + sizeof buf;
va_start(arg, fmt);
p = seprint(buf, e, %s:%d , t-file, t-line);
p = vseprint(p, e, fmt, arg);
p = seprint(p, e, \n);
va_end(arg);
write(2, buf, p - buf);
}
enum{
Base,
Seeneq,
};
int
yylex(void)
{
char buf[128], *s;
int c, i;
Rune r;
static int state = Base;
static int quoting;
if(quoting != 0){
yyerror(bad quote);
quoting = 0;
}
i = 0;
again:
c = Bgetrune(in);
if(c == Beof)
return 0;
r = c;
switch(r){
case '
':
case '\0':
yyerror(bad character %#ux\n, r);
goto again;
case '#':
for(;;){
switch(Bgetrune(in)){
case Beof:
yyerror(EOF in comment);
return 0;
case '\n':
Bungetrune(in);
goto again;
}
}
case '\n':
if(state != Base){
Bungetrune(in);
goto tok;
}
line++;
switch(Bgetrune(in)){
case Beof:
return '\n';
case
Re: [9fans] A little more ado about async Tclunk
No! Open on an exclusive file has the same races. No problems on Froggie .. no servers with clunk semantics. The first I encountered was Bosch's video streamer. Nemo obviously has concerns. Catch a run. brucee On Fri, Oct 29, 2010 at 10:51 AM, Gorka Guardiola pau...@gmail.com wrote: On Thu, Oct 28, 2010 at 10:18 PM, Charles Forsyth fors...@terzarima.net wrote: the race is that there's nothing to say that the clunk completes before the process continues on to do something more, including some action that depends on the clunk completing, such as simply repeating the open. that open can fail if the mode or the name imposes particular constraints; constraints that depend on the order of events as expressed by the process. What you are saying is that the problem could be something like: - Tclunk (do not wait for response) - Topen (the file is exclusive) Then somehow in the server, Tclunk and Topen are reordered because they are managed by different threads and Topen gets an error because the file is already opened. This is a problem, I agree. On Oct 28, 2010, at 10:32 PM, Venkatesh Srinivas m...@acm.jhu.edu wrote: On a decent server, since clunk cannot fail and won't launch the missiles, you can't really do anything that would depend on the result anyway. Tclunk may be a good time to commit to disk or do other unmissile like thing. You can switch to another cache after waiting for the Rclunk, for example. Decent or not indecent I am more and more conviced after this thread that Tclunk should be synchronous. Even in decent files Tclunk can have some side effects.
