Re: [9fans] Nupas truncated e-mail
On Wed Mar 11 12:44:02 EDT 2009, m...@gmx.net wrote: > > % cat /mail/fs/mbox/99/unixdatesec > 1236524327.00 > % ls -l /mail/box/mn/mbox/1236524327.00 > --r M 226874 mn mn 352001 Mar 9 15:33 /mail/box/mn/mbox/1236524327.00 > % cmp /mail/box/mn/mbox/1236524327.00 /mail/fs/mbox/99/rawunix > EOF on /mail/fs/mbox/99/rawunix after 335937 bytes > are you running the latest version of nupas? this looks like a bug that has been fixed, but it may have popped up in a different form. if you are using the latest and still have trouble, contact me offline so we can debug the problem. - erik
[9fans] drawterm crash. small fix. bug remains?
ignominously, i am dealing with an x86_64 linux
machine with 64-bit linux. this always crashes
drawterm
1. create new rio window
2. put window in hold mode
3. cut from an x application
4. paste into drawterm window from #2.
this change stopped it from crashing. i don't
know if this is a recent change to the x11 headers.
diff -c x11.c /root/drawterm/gui-x11/
x11.c:1426,1432 - /root/drawterm/gui-x11//x11.c:1426,1432
uchar *data, *xdata;
Atom clipboard, type, prop;
unsigned long lastlen;
- unsigned long dummy, len;
+ uint dummy, len;
int fmt, i;
Window w;
but i'm not fully convinced that it's all better. i
may just be masking the problem. notice that
c->aux == c in the following debugging output.
it may be just a coincidence, but i'm not so sure.
(gdb) r
Starting program: /root/drawterm/drawterm --c ladd
[Thread debugging using libthread_db enabled]
[New Thread 0x7f855c18c6f0 (LWP 9620)]
[New Thread 0x42455950 (LWP 9621)]
[New Thread 0x42c56950 (LWP 9627)]
[New Thread 0x43457950 (LWP 9628)]
[New Thread 0x43c58950 (LWP 9629)]
[New Thread 0x44459950 (LWP 9630)]
[New Thread 0x412be950 (LWP 9631)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x43c58950 (LWP 9629)]
0x0040aefa in consread (c=0x7f85, buf=0x6e36a0,
n=, off=0) at devcons.c:762
762 c->aux = clipread();
(gdb) print c
$1 = (Chan *) 0x7f85
(gdb) print *c
Cannot access memory at address 0x7f85
(gdb) where
#0 0x0040aefa in consread (c=0x7f85, buf=0x6e36a0,
n=, off=0) at devcons.c:762
#1 0x004125f7 in kread (fd=, buf=0x6e36a0,
n=, offp=0x43c57b90) at sysfile.c:408
#2 0x00412665 in _syspread (fd=6877216, buf=0x7f855b830320, n=7388928,
off=0) at sysfile.c:435
#3 0x00412722 in syspread (fd=10, buf=0x6e36a0, n=1024, off=0)
at sysfile.c:1046
#4 0x00425356 in slaveread (p=0x6b8770) at exportsrv.c:606
#5 0x004256f9 in blockingslave (x=) at
exportsrv.c:496
#6 0x00415173 in tramp (vp=) at posix.c:130
#7 0x7f855ba6c097 in start_thread () from /lib/libpthread.so.0
#8 0x7f855b7e3ccd in clone () from /lib/libc.so.6
#9 0x in ?? ()
(gdb) up
#1 0x004125f7 in kread (fd=, buf=0x6e36a0,
n=, offp=0x43c57b90) at sysfile.c:408
408 n = devtab[c->type]->read(c, buf, n, off);
(gdb) p c
$2 = (Chan *) 0x7f8554001960
(gdb) up
#2 0x00412665 in _syspread (fd=6877216, buf=0x7f855b830320, n=7388928,
off=0) at sysfile.c:435
435 return kread(fd, buf, n, &off);
(gdb) down
#1 0x004125f7 in kread (fd=, buf=0x6e36a0,
n=, offp=0x43c57b90) at sysfile.c:408
408 n = devtab[c->type]->read(c, buf, n, off);
(gdb) p c->type
$3 = 1
(gdb) p c
$4 = (Chan *) 0x7f8554001960
(gdb) p c->aux
$5 = (void *) 0x7f8554001670
(gdb) p *c
$6 = {ref = {lk = {key = 0}, ref = 2}, next = 0x0, link = 0x7f8554001870,
offset = 0, type = 1, dev = 0, mode = 0, flag = 1, qid = {path = 19, vers =
0,
type = 0 '\0'}, fid = 133, iounit = 0, umh = 0x0, umc = 0x0, umqlock = {lk
= {
key = 0}, hold = 0x0, first = 0x0, last = 0x0}, uri = 0, dri = 0,
mountid = 0, mcp = 0x0, mux = 0x0, aux = 0x7f8554001670, pgrpid = {path = 0,
vers = 0, type = 0 '\0'}, mid = 0, mchan = 0x0, mqid = {path = 0, vers = 0,
type = 0 '\0'}, session = 0x0, name = 0x7f85540008c0}
(gdb) down
#0 0x0040aefa in consread (c=0x7f85, buf=0x6e36a0,
n=, off=0) at devcons.c:762
762 c->aux = clipread();
(gdb) p c
$7 = (Chan *) 0x7f85
- erik
Re: [9fans] drawterm crash. small fix. bug remains?
nevermind. i guess this is the right fix. evidently i had a little dyslexic fit at 2 in the morning. as 0x7f8554001670 != 0x7f8554001960 - erik
Re: [9fans] Realtek 8111C
works fine for me, even with jumbo packets: 5.0.0: net 02.00.00 10ec/8168 10 0:d801 256 2:feaff004 4096 3: 16 Realtek Semiconductor RTL8168/8111 Gigabit Ethernet NIC(NDIS 6.0) i'm too lazy to check if it's exactly a 8111c, but i've never had trouble with realtek 8169-style controllers. - erik
Re: [9fans] Realtek 8111C
On Thu Mar 12 18:35:33 EDT 2009, aris...@ar.aichi-u.ac.jp wrote: > Hello, > > I tried 8111C on GIGABYTE GA-G31M-S2L, > but the controller did not work for me. > I don't know if recent driver works. > Additional information welcome. > > Kenji Arisawa i am running a slightly different driver than the one on sources. (i just put it in /n/sources/contrib/quanstro/ether8169.c). i never had any trouble with the driver at all. the differences are due to some changes i needed to make to support jumbo frames. i used the linux driver for comparison. one or two of the sources driver's registers may be slightly misset, maybe this driver will work for you (modulo did). - erik
Re: [9fans] Toshiba Tecra 700CT cannot install
> Ok, here's the deal. > > I've made a floppy boot, as the BIOS doesn't have a cd boot option, > it's either floppy or hard drive. > When I boot from floppy it detects it as fd0 which is expected, but > that's the only thing it sees. > I tried every combination of xx! that I could and nothing works. > I tried putting the iso on the FAT partition, still a no go. > > I know the comuter works, because I've installed both windows 98SE, > and linux (at different times) > > If anyone has any ideas it would be much appreciated. I use to have > plan9 on a older computer years ago, and wanna get it on this brick of > a laptop. the output of lspci -nk would be useful. you can use this yourself to check /sys/src/9/pc/sdata.c and /sys/src/boot/pc/sdata.c for the ide devices on this machine. my guess is that they're not listed. - erik
Re: [9fans] new toy - gmap
> key matches? Do they do a reverse lookup on the IP address, or do > they use something in the http transaction? since it's assumed this is embedded on your website somewhere, they can't do either, since it's the client doing the requesting. referrer url (or whatever it's called — it's been a long time) isn't required in the headers. - erik
Re: [9fans] log oversight
> is it a shortcoming compared to unix world? these logs > are not sacrosanct. > linux typically uses log daemons to do the actual logging. unless they are encrypting all those channels, even from untrusted agents like smtp daemons, i don't know how you provide better security. actually plan 9 has one big advantage: the append-only flag. the worst a rogue agent can do is waste disk space. the plan 9 solution isn't perfect, but a better solution would be many times more complex. - erik
Re: [9fans] log oversight
> An alternative for the paranoid perhaps would be to make an additional fs > (in fossil) containing the log files. This fs could be set to accept only > the hostowner's credentials for attach requests. The hostowner, meanwhile, > when constructing namespaces, could bind the right file(s) into the log > directory. I haven't thought it through in more detail than that, but if I > were to engineer a replacement, that's how I'd start. HTH. this would give you exactly the same security behavior as we currently have, but if the fd were ever closed or dup(2)'d over, syslog(2) would stop working. - erik
Re: [9fans] THnX status?
> You say 'skip lguest' -- that's fine. But what's the best alternative > for running Plan9 server > on the same bare metal that needs to run something else? more hardware ☺ - erik
Re: [9fans] THnX status?
> NetBSD runs on ESX at the same time as Plan 9 and it switches off > reproduceably pretty abruptly when I try to FTP the GNU directory from > gnu.org, good to see the netbsd guys have taste! - erik
Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
On Tue Mar 17 18:17:53 EDT 2009, urie...@gmail.com wrote: > Thanks Geoff for the prompt explanation, but I'm getting the same > results with ifs=() Not sure why, but I'm not sure I understand the > difference between setting ifs to '' and (). in your test, try this echo $#x - erik
Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
On Tue Mar 17 18:29:14 EDT 2009, urie...@gmail.com wrote:
> Thanks martin for your analysis, this makes some sense to me, but as I
> pointed out, even setting ifs to () doesn't solve the issue, so it
> would be nice to find a solution to this.
>
> Right now having the output of `{} corrupted can be quite inconvenient...
it is unreasonable to expect to be able to generate tokens
that are bigger than 8k. however, the '8' should not
be dropped. i would think this small change would be worth
consideration.
; diffy -c havefork.c
/n/dump/2009/0317/sys/src/cmd/rc/havefork.c:74,80 - havefork.c:74,80
Xbackq(void)
{
char wd[8193];
- int c;
+ int c, trunc;
char *s, *ewd=&wd[8192], *stop;
struct io *f;
var *ifs = vlook("ifs");
/n/dump/2009/0317/sys/src/cmd/rc/havefork.c:105,113 - havefork.c:105,116
while((c = rchr(f))!=EOF){
if(strchr(stop, c) || s==ewd){
if(s!=wd){
+ trunc = s == ewd;
*s='\0';
v = newword(wd, v);
s = wd;
+ if(trunc)
+ *s++ = c;
}
}
else *s++=c;
- erik
Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
> >> Right now having the output of `{} corrupted can be quite inconvenient...
> >
> > it is unreasonable to expect to be able to generate tokens
> > that are bigger than 8k.
>
> Well, I would prefer if such limit didn't exist ;) But it doesn't seem
> like a totally unreasonable limit either.
why can't you just let ifs = $newline (formatted to fit your screen) ?
- erik
Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
On Tue Mar 17 20:29:50 EDT 2009, urie...@gmail.com wrote: > > why can't you just let ifs = $newline (formatted to fit your screen) ? > > Unfortunately that doesn't work in this case, my input is HTTP post > data, which is a single line of URL-encoded text which I have to > decode into multiple parameters of arbitrary length. why not write a small program to crack the post data. might take ½ an hour, tops. - erik
Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
> 2009/3/17 erik quanstrom :
> > it is unreasonable to expect to be able to generate tokens
> > that are bigger than 8k.
>
> i'm not sure i agree. they're not just tokens, they're strings,
> and there are lots of reasons why one might wish to
> have a string longer than 8k read from a file. i've certainly done so
> in inferno's sh, which doesn't have this restriction.
you win.
couple of notes -
* same changes to haven't fork, omitted for clarity
* erealloc should be in subr.c and declared in rc.h
and should be supported by Realloc in (plan9
unix win32)^.c
* there are two other calls to realloc that should
be addressed, too.
* the if guarding efree prevents a "free 0" whine.
havefork.c:67,81 - /n/dump/2009/0316/sys/src/cmd/rc/havefork.c:67,72
}
}
- char*
- erealloc(char *p, long n)
- {
- p = realloc(p, n); /* botch, should be Realloc */
- if(p==0)
- panic("Can't realloc %d bytes\n", n);
- return p;
- }
-
/*
* Who should wait for the exit from the fork?
*/
havefork.c:82,89 - /n/dump/2009/0316/sys/src/cmd/rc/havefork.c:73,81
void
Xbackq(void)
{
- int c, l;
- char *s, *wd, *ewd, *stop;
+ char wd[8193];
+ int c;
+ char *s, *ewd=&wd[8192], *stop;
struct io *f;
var *ifs = vlook("ifs");
word *v, *nextv;
havefork.c:108,127 - /n/dump/2009/0316/sys/src/cmd/rc/havefork.c:100,115
default:
close(pfd[PWR]);
f = openfd(pfd[PRD]);
- s = wd = ewd = 0;
+ s = wd;
v = 0;
while((c = rchr(f))!=EOF){
- if(s==ewd){
- l = s-wd;
- wd = erealloc(wd, l+100);
- ewd = wd+l+100-1;
- s = wd+l;
+ if(strchr(stop, c) || s==ewd){
+ if(s!=wd){
+ *s='\0';
+ v = newword(wd, v);
+ s = wd;
+ }
}
- if(strchr(stop, c) && s!=wd){
- *s='\0';
- v = newword(wd, v);
- s = wd;
- }
else *s++=c;
}
if(s!=wd){
havefork.c:128,135 - /n/dump/2009/0316/sys/src/cmd/rc/havefork.c:116,121
*s='\0';
v = newword(wd, v);
}
- if(wd)
- efree(wd);
closeio(f);
Waitfor(pid, 0);
/* v points to reversed arglist -- reverse it onto argv */
- erik
Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
On Wed Mar 18 09:54:54 EDT 2009, rogpe...@gmail.com wrote: > 2009/3/18 erik quanstrom : > > - ewd = wd+l+100-1; > > one small comment, based on a totally superficial scan of that diff: > might it not be better to grow the buffer by some multiplicative > factor, to avoid linear behaviour when reading large files? > i often (for no particularly good reason) use 50% as a growth > factor - it doesn't seem as radical as *2, but will still work ok > in the long run. i have two arguments against doing expontential growth: - other dynamicly allocated buffers in rc are allocated in increments of 100 bytes. - the linear behavior would only be for long *tokens*. the length of the input is irrelavant. only in the case of tokens >= 100 chars would there be a second call to realloc. the total cost is O(maximum token length) for the whole input. how could this be a problem? - erik
Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
On Wed Mar 18 06:33:49 EDT 2009, mattmob...@proweb.co.uk wrote: > Using rc in werc neutralizes OS differences to a certain degree, > obviously some things catch one out, such as this one. (and just wait > until a \0 comes along!) this is an easy problem to solve: tr '\0' '☺' - erik
Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook
> so, here's a silghtly controversial (maybe) suggestion. Maybe my > memory is wrong, but i believe the vx32 kernel is gcc-compiled. There > is gcc for this CPU. It might be easier to start from the vx32 kernel > and gcc to target this machine, rather than do a 64-bit MIPS port of > the plan 9 C compiler. Or not: a few of the folks on this list could > probably retarget in very short order (I'm not one of the,however). vx32 relies on x86 segment registers. - erik
Re: [9fans] Raw Input Driver
On Fri Mar 20 03:58:26 EDT 2009, ja...@orcasystems.com wrote:
> I am also looking for advice on what people might like for the
> interface, right now I am using:
>
> struct InputEvent {
>intmsec;
>unsigned short type;
>unsigned short code;
>intvalue;
> };
the old objections notwithstanding, i think this is a good idea.
one can easily emulate the old interface with a combined kbd/mouse
interface in libary with the added bonus that it's harder to get misordered
kbd/mouse events which can be a problem on lossy wireless networks
(don't you hate it when your acme clicks and types get out-of-wack?)
and the ability to see more of the kbd state.
if you want to do this, think it terms of a devce, say /dev/input.
most plan 9 devices of this type have a text interface. see mouse(3).
this format could easily be extended so that mouse is as before
and keyboard events are presented as 'k ' char[11] ' ' scancode[11] ' '
msec[1 - 24]. one would imagine mod being a bit vector of
the normal mode keys encoding plus a bit for key press/release.
already has a reasonable definition for mouse events.
by analogy,
typedef struct Keyboard Keyboard;
struct Keyboard {
Runec;
uintsc;
uvlong msec;
};
then
typedef struct Input Input
struct Input {
int type; /* 'k' or 'm' */
union{
Keyboard
Mouse
};
};
and finally
typedef struct Inputctl Inputctl;
struct Inputctl
{
Channel *c; /* chan(Input[20]) */
char*file;
int inputfd;/* to input file */
int ctlfd; /* to ctl file */
int pid;/* of slave proc */
};
i'm glossing over dealing with mouse vs keyboard control
events.
the work is building this into the kernel and rio. i think
it would make sense for keyboard(2) and mouse(2) to
be emulated in terms of the new interface for syncronization
reasons.
once you've torn all that up, it will be a trivial undertaking to
get your shift release event. ☺
- erik
Re: [9fans] Raw Input Driver
On Fri Mar 20 07:40:30 EDT 2009, n...@lsub.org wrote: > If connection is slow (as the one I'm using now) increasing the > abstraction level is a good thing to do. Merging low level input > streams may patch up things for a while, but won't be enough > if the connection is slower. i think it does solve the originally stated problem — keeping input streams in sync, which is a problem for a local viewer if any input-handling proc does potentially-blocking i/o. john carmack mentioned this way back when: http://9fans.net/archive/1995/11/123 i suppose thinking of this as a real-time problem could make sense, but simply keeping order would seem to me to be a useful subset of the whole problem. - erik
Re: [9fans] Raw Input Driver
this is mostly a repeat of what rog. said. i'm a slow thinker, but i'll subject y'all to what i was thinking anyway > the ordering problem is misleading: you need timely response for > interactive applications; it's a reasonably straightforward application > of real-time programming. (by the way, if you're passing low-level > things like that across lossy wireless networks, you're possibly > not addressing the most relevant problem first.) the effects you're trying > to synchronise > are typically changes to data structures inside a program (including effects > on the display), > so that's where the synchronisation and interlocking should be. > that's fine. but what acme does doesn't work. i'm sure everyone here has typed something in one acme window and had it appear in another. almost always, the keyboard and mouse are connected to the "same" hardware. and it's people realtime not real realtime. so it seems to me that this problem should not exist. and it seems to me that the problem is exactly that the kbd and mouse are on seperate channels. what i proposed will work when all the input devices are connected to the "same" hardware. a combo usb kb/mouse or a standard pc kb and mouse would qualify. applications like acme would not need any modification, though libraries would. what do you propose? > it's not as though the underlying devices > weren't separate streams; they are, and it makes sense for the view > of them to reflect that. it also makes it easier to add new input > devices. i see already you've got 'k' and 'm', with surprisingly different > content, but what about that fingerprint thingy to unlock the cheats? or > perhaps more to the point the > 'w' for wheel and 'p' for pedals? you'll never finish. you have this problem regardless of implementation strategy. but this is mostly argued in the moot court as most such devices act like either a keyboard or a mouse. - erik
Re: [9fans] Raw Input Driver
> >it's people realtime not real realtime. > > the former is an example of the latter. > real-time is meeting deadlines. deadlines are always real, if you've got them. > there isn't a distinction based on speed (ie, 1 usec is "real", but 10ms is > not). > any hard/soft distinction is typically based on whether the program can miss > a deadline, > and the consequences. my point was that the consequences for occassional misses are just a reduced perception of responsiveness. for most applications, this should be okay. i would think it would be an undue burden to break out the realtime tools for any program that has a ui. (not related to my point, what about a time frame of 1 minute? one day?) - erik
Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook
> Let me say it differently. The way in which the plan 9 kernel code was > changed to be gcc-compilable as part of the vx32 kernel might provide > some hints as to how to change a whole plan 9 kernel. The point being, > it is not impossible to get a gcc-compilable plan 9 kernel. We used to > talk about this at LANL all the time: we called it the "evil project". > (This idea predates vx32 but it was not my idea; I will let the evil > person behind the evil project identify himself). This change would > remove "have to port&test&validate&fix&validate&... the C compiler > first" as a barrier to entry on new CPUs. > > see src/vx32 in the vx32 tree. i'm really missing something. what executables does this kernel run? how are they generated? wouldn't it just be easier to use 32-bit compatability mode (http://www.mips.com/products/processors/architectures/mips64/) for bootstrapping using vc? - erik
Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort
On Fri Mar 20 11:34:28 EDT 2009, lu...@proxima.alt.za wrote: > > wouldn't it just be easier to use 32-bit compatability mode > > (http://www.mips.com/products/processors/architectures/mips64/) > > for bootstrapping using vc? > > Please don't go there! I have just ordered (and paid for) one of > those gadgets and foremost in my mind was the hope that I would not > have to deal with a BIOS that needed emulation to be executed. what leads you to believe that you need to call their open bios, it doesn't deal with 32-bit mode, it can't be modified to deal with 32-bit mode and mode switching is impracticable? (or whatever the correct order is.) - erik
[9fans] hardware idea
i think this marvell media vault soc has quite a bit of promise. this product seems to be an arm core + a mashup of other marvell parts. the sata controller appears to have the same register interfaces as the one driven by sdmv50xx.c. the ethernet controller is not currently supported, but there appears to be enough documentation to support it. (as an added bonus, though i haven't had a chance to check in detail, i would guess this would help support x86 marvell lom parts (mv643xx) as well!) http://www.marvell.com/products/media/index.jsp the "User Manual" has all the crunchy register specs. here's a few products based on this soc: http://www.portwell.com.tw/products/NAD-1004_ca.html http://www.newegg.com/Product/Product.aspx?Item=N82E16822165130 it would be so much nicer running a plan 9. - erik
Re: [9fans] fossil periodic thread does zero sleep()
> Can anybody explain this fossil behaviour from the periodic code? what if 0 < t - ct < 1? wouldn't it be a good idea to replace the doubles with vlongs? and replace *1e-6 with /100? that would make 0 < t - ct < 1 impossible. - erik
Re: [9fans] fossil periodic thread does zero sleep()
what is your HZ set at? after chasing a few bugs like this, i've set HZ=1000. actually i first saw the idea in sam hopins' work there's no performance drag and 1 ms sleeps do actually sleep. - erik
Re: [9fans] fossil periodic thread does zero sleep()
> The problem is that when sleep is a little bit too fast on every round, > t will never catch up with ct. so it sleeps shorter and shorter until > t - ct < 1. > > It all works when changing t += msec to t = ct + msec. It may still > do a zero sleep, but the error will not add up. why not just get rid of the double? then you will never zero sleep. - erik
Re: [9fans] hardware idea
> Probably easier to develop on: > > http://www.embeddedarm.com/products/board-detail.php?product=TS-7800 > > The NAND annoyingly is not via the SoC and there are a few other quirks > however as you can boot off the SD card (making it unbrickable and dead > easy to play with kernel dev work), it has real serial ports where you > do not have to faff with to get them and of course the SATA ports. nice find. thanks. too bad it doesn't expose all 4 sata ports. and way too bad that currently 0 < toy budget < $1. - erik
Re: [9fans] hardware idea
On Mon Mar 23 19:04:28 EDT 2009, cinap_len...@gmx.de wrote: > maybe use vlongs for your toy budget too? :) vlongs don't spend well. ☺ - erik
Re: [9fans] grist for the "synchronous vs. asynchronous" mill
On Tue Mar 24 08:54:12 EDT 2009, rogpe...@gmail.com wrote: > http://www.classhat.com/tymaPaulMultithread.pdf seems more like grist for the task vs. process debate. not that the outcome is in doubt. - erik
Re: [9fans] hardware idea
> The Marvell SoC only has the one controller with two ports going out > anway so I am pretty sure it's a SATA port multiplier you would be > playing around with in there, and that's going to be fustrating. it has one controller with 2 edma units (ports). see p. 70, chp 8 fig. 14 of http://www.marvell.com/files/products/media/88F5182_User_Manual.pdf for details. this is similar to ahci which can have up to 32 ports per controller without a port multiplier. - erik
Re: [9fans] grist for the "synchronous vs. asynchronous" mill
> On Tue, Mar 24, 2009 at 6:34 AM, erik quanstrom wrote: > > On Tue Mar 24 08:54:12 EDT 2009, rogpe...@gmail.com wrote: > >> http://www.classhat.com/tymaPaulMultithread.pdf > > > > seems more like grist for the task vs. process > > debate. not that the outcome is in doubt. > > except that they only went to 1000 threads. Once we hit more than > that, linux fell over badly for us on even a big machine. i assume it didn't fall over uniformly. what was the weak point? scheduling? - erik
[9fans] kernel tag bug?
it looks like devcons is suffering from some sort of tag collision. a Rwrite is coming back for a Tread. Sat Jan 24 09:43:47: mnt: proc rc 10946: mismatch from /mnt/temp/data /dev/cons rep 0xf63661a8 tag 1 fid 1170 T116 R119 rp 1 Sat Jan 24 10:06:26: unexpected reply tag 1; type 117 Fri Jan 30 15:21:48: 336082 page: checked 75 page table entries Wed Mar 18 11:27:27: mnt: proc rc 4632855: mismatch from /mnt/temp/data /dev/cons rep 0xf69e84e8 tag 37 fid 5644 T116 R119 rp 37 i don't immediately see the cause of the problem. - erik
Re: [9fans] drawterm font
> I ask because my 'bootes' account's profile doesn't start rio, so I > occasionally use it to do command-line-only administration things, > like adding users. why not drawterm as yourself and "cpu -u bootes" if you can't access the console via C? - erik
Re: [9fans] Plan 9 on Routers?
> Maybe there is a filesystem that exposes the kernel routing table to > user space for certain routing algorithm scripts to hack upon? #I publishes routes in iproute, typically bound so that this appears as /net/iproute. that's probablly a good start. - erik
Re: [9fans] kernel tag bug?
On Tue Mar 24 16:00:54 EDT 2009, r...@swtch.com wrote: > On Tue, Mar 24, 2009 at 10:59 AM, erik quanstrom > wrote: > > it looks like devcons is suffering from some sort of tag collision. > > a Rwrite is coming back for a Tread. > > > > Sat Jan 24 09:43:47: mnt: proc rc 10946: mismatch from /mnt/temp/data > > /dev/cons rep 0xf63661a8 tag 1 fid 1170 T116 R119 rp 1 > > Sat Jan 24 10:06:26: unexpected reply tag 1; type 117 > > Fri Jan 30 15:21:48: 336082 page: checked 75 page table entries > > Wed Mar 18 11:27:27: mnt: proc rc 4632855: mismatch from /mnt/temp/data > > /dev/cons rep 0xf69e84e8 tag 37 fid 5644 T116 R119 rp 37 > > > > i don't immediately see the cause of the problem. > > i've seen this for years in various forms > but it had never happened regularly enough > to track down, and it was never clear that it > was the kernel's fault (and not, say, the 9p server). doesn't the kernel get credit either way? either it's the source (devmnt) or the server (devcons). am i missing something? > if i interrupt an outstanding 9p message by > typing DEL. 9fs sources; ls /n/sources; DEL interesting. maybe the read was interrupted. devmnt picked the same tag for a write and immediately got the interrupted read back. - erik
Re: [9fans] Plan 9 on Routers?
> It seems that /net/iproute is where I can start. It has a complete > interface for editing routes. What we need is a user space script that > implements routing, like http://www.openbgp.org/ does on OpenBSD. > Except that, it will only have to send add, delete and flush control > messages to the iproute file. see ipconfig(8). > About Packet Classification. I read that iptables is not needed on > Plan 9 because its "mount /net over the network" concept achieved > anonymity or transparency -- something along those lines. "There are > no logs about who is sending what, and that is a good thing". that's not strictly true. as long as you restrict your network to plan 9 machines, it is possible to import /net from a gateway machine and avoid sticky things like packet filtering. there is also ipmux (discussed in ip(3)). i don't think ipmux has enough rewriting (or state) to implement something like nat. - erik
Re: [9fans] Plan 9 on Routers?
> I believe I have a rudimentary and probably non-working (at this > point) packet filter in /n/sources/contrib/dho somewhere (it was > written at least 4 years ago). I think it's called ``nfil.'' I > believe it is desirable. Others disagree. Its usefulness is related > directly to its application, and without it, there's no way to test > Plan 9 in an environment in which it would be useful. why not extend the packet filtering capabilities of the existing #I? - erik
Re: [9fans] request for more GSoC project suggestions
> Gogo reimplementation of cfront. i'm pretty sure c++ has "advanced" to the point where the cfront implementation technique is unworkable. - erik
Re: [9fans] request for more GSoC project suggestions
On Wed Mar 25 19:22:23 EDT 2009, devon.od...@gmail.com wrote: > Another student I spoke to on IRC spoke of the possibility of > bootstrapping LLVM for Plan 9 on Linux and getting it to run natively. > That would give us a whole bunch of different compilers. > > --dho at the risk of being called stupid twice in one day, i have to say i don't see what the payoff would be. doing something with gcc helps with gcc-specific code. what does llvm give us? - erik
Re: [9fans] request for more GSoC project suggestions
On Wed Mar 25 16:39:16 EDT 2009, cmbran...@cox.net wrote: > > > Gogo reimplementation of cfront. > > > > i'm pretty sure c++ has "advanced" to the point where > > the cfront implementation technique is unworkable. > > The Comeau C++ compiler [1] uses the cfront technique, doesn't it? It is > supposed to be very standards-compliant. > > [1] http://www.comeaucomputing.com where do they claim this? i see a claim that they accept cfront-isms, but that's a different claim. - erik
Re: [9fans] GSOC: Drawterm for the iPhone
> > ok, you can't compare porting inferno to the ds with drawterm for the iphone > > drawterm is an app to get to a Plan 9 server, inferno is a self contained > > operating system where you can get the advantage of writing your > > own apps for it. > > Except that drawterm ends up being a mini-Plan 9 kernel like > everything else out there. The concepts aren't so different. the devices drawterm does provide are not essential parts of the kernel. the fact that drawterm exists is proof. - erik
Re: [9fans] request for more GSoC project suggestions
> I think the gist behind LLVM is that compilers can target it as a > machine type, and it is able to create native binaries for its own > supported machine type for anything that can run on it. So any > compiler that can target LLVM would be able to target Plan 9. (Which > is several of them) at what point does indirection become misdirection? but writing a compiler is a small task in comparison to dealing with the platform. (writing drivers, dealing with memory, etc). how does llvm deal with that? if it doesn't, then inferno is superior by providing a virtual platform. - erik
Re: [9fans] GSOC: Drawterm for the iPhone
On Thu Mar 26 08:53:03 EDT 2009, urie...@gmail.com wrote: > Porting drawterm is a dead end with very little potential of either > learning anything interesting or being useful in the future. inferno is a red herring. you might as well suggest qnx as an alternative. while drawterm might not be appropriate as is for the platform in question, drawterm is still the best option for connecting to a localish plan 9 system from a machine that's not running plan 9. it requires no local administration. that's a big deal. i already have two independent systems and 50 users to manage. 9vx could replace drawterm in our environment, but i think the following work is required. 9vx needs - to be able to boot with no local files other than the executable, (i.e. directly from a plan 9 fs) - to have native networking built in, - to be harmonized with plan 9 devices. (i don't think users will accept "if you're on 9vx, do this; if you're on a cpu server, do that".) (booting from a plan 9 fs could be an interesting gsoc project, especially if the kernel were (sort-of) pxe loaded so that clients would only need a local copy of the loader and changes would then be automaticly distributed.) so please stop saying that 9vx or inferno make drawterm obsolete until that's actually true. - erik
Re: [9fans] new toy - gmap
On Thu Mar 26 04:42:48 EDT 2009, lu...@proxima.alt.za wrote:
> > Pick up the new code, it reads the key from /lib/gmapkey
> > and gets the longditude and latitude the correct way round
> > (as several people have told me.
>
> I use:
>
> lng=`{echo $here(2) | sed -e 's/^-(.*)/+\1/' -e 's/^([0-9])/-\1/'}
>
> Because double negatives (--) don't seem to cut it in the URL :-)
> I imagine there's a better way, but rc programming is not my strong
> suit. And I can't test now the simplification that drops the \1 from the
> first term.
this was my approach. just remove any leading --.
/n/dump/2009/0326/rc/bin/gmap:5,11 - /rc/bin/gmap:5,11
gmapkey = `{cat /lib/gmapkey}
here = `{cat /lib/sky/here}
lat = $here(1)
- lng = -$here(2)
+ lng = `{echo -$here(2) | sed 's/^--//g'}
if(~ $#gmapkey 0){
echo goto http://code.google.com/apis/maps/signup.html and get a google
maps key (free)
> I got caught by the fact that the space after -e is mandatory (why?)
> and the first \1 belongs to me trying to figure out what I was doing
> wrong.
this is due to non-standard usage of ARGF.
it might be a good idea to replace the continues
between ARGBEGIN and ARGEND with break.
currently ARGEND doesn't do anything, but one
could imagine a different implementation that does.
- erik
; diff -c sed.c /sys/src/cmd/
sed.c:203,209 - /sys/src/cmd//sed.c:203,208
void
main(int argc, char **argv)
{
- char *p;
int compfl;
lnum = 0;
sed.c:215,230 - /sys/src/cmd//sed.c:214,229
exits(0);
ARGBEGIN{
case 'e':
- if ((p = ARGF()) == nil)
+ if (argc <= 1)
quit("missing pattern");
- newfile(P_ARG, p);
+ newfile(P_ARG, ARGF());
fcomp();
compfl = 1;
continue;
case 'f':
- if ((p = ARGF()) == nil)
+ if(argc <= 1)
quit("no pattern-file");
- newfile(P_FILE, p);
+ newfile(P_FILE, ARGF());
fcomp();
compfl = 1;
continue;
Re: [9fans] GSOC: Drawterm for the iPhone
> >> especially if the kernel were (sort-of) pxe loaded so that clients would > >> only need a local copy of the loader and changes would then be > >> automaticly distributed.) > > > > Now that could be fun. > > > > I smell the feminine stench -- flowers and butterflies -- of GSoC project > proposal in every character of that message. > > > or perhaps I have sinusitis > so this is all imagined i believe you owe the list an apology for this offensive and unacceptable comment. - erik
Re: [9fans] Inferno slow on Plan 9?
> Is there any reason this might be happening? If its related to > Inferno's /dev/draw, is there any way I can import /dev/draw from P9 > and use it in Inferno? Would that be faster? does the PAT register patch (/n/sources/patch/pat) make any difference? - erik
Re: [9fans] Inferno slow on Plan 9?
> The CPU doesn't support PATs, sorry. > > It does have MTRR support though, wasn't there a patch to support > Write-combining for the framebuffer region using them instead? > > FWIW, native graphics applications (including Hyperglenda) are very fast... if the slowdown is caused by reading the framebuffer, than the patch wouldn't help anyway. reading the frame buffer on certain nvidia cards (for example, mine) can be astoundingly slow. - erik
Re: [9fans] 9P writes for directories
> question: is there anything that HTTP makes us lose except > for the transactional nature of create? sanity? > to "create" would be POST with a metadata payload on a > "subdirectory" URI. But of course, it is not a create at all. i'm not sure what fine hair you're trying to split. why can't the post contain the same information a create would? - erik
Re: [9fans] 9P writes for directories
> >> to "create" would be POST with a metadata payload on a > >> "subdirectory" URI. But of course, it is not a create at all. > > > > i'm not sure what fine hair you're trying to split. why can't the > > post contain the same information a create would? > > > If "hair splitting" is the answer to the original question -- that's > completely fine. In fact, I was looking for that to be an answer. > It's just that everytime I see something being explicitly forbidden > in 9P spec there's usually a pretty good reason for that. i wasn't clear. why can't you gather up the data from the post and do a create rather than a write to the directory? - erik
Re: [9fans] 9P writes for directories
> It would (just as Erik pointed out). I guess I was just looking for > symmetry (if POST is really a write(*), it should translate into write > independent of whether the URI corresponds to a subdirectory or > not) and potential pitfalls that made 9P spec disallow writes on > subdirectories (and since nobody can identify any of those -- I'll > rest my case and proceed with translating POST into different > 9P messages depending on the type of the URI). the only thing that write and create have in common is the fact that they both translate to 9p messages. the beauty of create is that it is atomic. if you don't care about atomicity, you can just open if create fails. using write, the qid could not be returned and there would always be a race. since one would not have the qid, it would be impossible to tell if the race had been won. - erik
Re: [9fans] another webfs question
> It seems I'm hitting this error when sending some GET requests:
>
> In /sys/src/cmd/webfs/url.c:
>
> if(strstr(url, "%00")){
> werrstr("escaped NUL in URI");
> return -1;
> }
>
> I haven't fully understood the comment above, especially if it is against
> the RFC to have an escaped NUL in an url, but this can actually happen,
> at least with queries to a bittorrent tracker. For example when specifying
> the info hash of a specific torrent when sending a scrape request:
>
> http://bttracker.debian.org:6969/scrape?info_hash=%F1%AE%D2%E5%15%A0%BD%F1%41%54%9D%44%00%47%AB%97%81%2B%69%16
> (13th char in the info hash is a NUL)
>
> I get a reply to that one both with wget on linux or hget on plan 9,
> while webfs gives the error from the code above.
>
> So is it webfs that needs fixing for that case, or are the other tools
> breaking some RFC with that?
rfc2396 doesn't mention any restrictions; %00 is legal.
- erik
Re: [9fans] another webfs question
> Yeah, there aren't any. That's the point of URL encoding; NULL bytes > are as acceptable as any other, and your client should be able to > handle them -- so I think that webfs check is just bogus. It should > just encode it as a \0 and pass it through. (you do mean %00 should result in a byte with value 0, not two bytes (in c notation) '\\' and '0', right?) assuming that every application that uses webfs is prepared to handle a null byte in the middle of a string. what webfs does — complaining loudly — is much preferrable to programs misbehaving silently. since it's quite likely that plan 9 applications are not going to properly deal with a null in a string, it's probablly a good implementation strategy unless you're willing to test all the programs that use webfs to make sure that this case is properly handled. - erik
Re: [9fans] another webfs question
> > assuming that every application that uses webfs is prepared
> > to handle a null byte in the middle of a string. what webfs does
> > — complaining loudly — is much preferrable to programs misbehaving
> > silently. since it's quite likely that plan 9 applications are not
> > going to properly deal with a null in a string, it's probablly
> > a good implementation strategy unless you're willing to test
> > all the programs that use webfs to make sure that this case
> > is properly handled.
>
> Ok, but then valid applications such as this one can't use webfs. I
> think something needing this could solve the issue by having the
> application import webfs into its own namespace, and then sending some
> sort of ctl command telling it to set an option to allow null bytes.
read to the end:
> > unless you're willing to test
> > all the programs that use webfs to make sure that this case
> > is properly handled.
i think it would be a bad idea to add a control swizzle bit
to avoid testing. testing is not that hard.
grep webfs `{find /sys/src /rc/bin |grep '\.[chy]$'} | grep -v /webfs/
/sys/src/cmd/webcookies.c: * Cookie file system. Allows hget and multiple
webfs's to collaborate.
/sys/src/cmd/webfsget.c:/* Example of how to use webfs */
/sys/src/cmd/webfsget.c:fprint(2, "usage: webfsget [-b baseurl] [-m
mtpt] [-p postbody] url\n");
you can search contrib, too. i'm sure that abaco falls on
its face when confronted with a 0 in a url.
- erik
Re: [9fans] fossil caching venti errors
On Sat Mar 28 06:54:35 EDT 2009, fors...@terzarima.net wrote: > i've seen that just recently, but thought it might have been > a failing (very old) drive, or a power failure beyond the endurance of the > UPS. > if neither of those are true in your case, it might be worth a deeper look. > i also found there is a persistent problem that `check fix' won't fix. > (since it's my principal file server at home, i can't easily investigate more > until i can transfer the service to a new drive, leaving the old drive > for experiment.) i hope this is useful information, but i fear it might not be. if the very old disk in question is a scsi disk, disk/smart in my contrib area should be gentle enough to run on a live server with any kernel. if the very old disk in question is an ata disk, disk/smart requires the sd changes in my contrib area to run raw ata commands like smart return status. it is also should be gentle enough to run on a live server. unfortunately, disk/smart is not smart enough to access ata general purpose logging information (gpl), yet. manufacturer diagnostic tools are still helpful here but require booting into dos. by the way, i think there are a number of interesting gsoc projects related to devsd and ata. for example, a devsd device that adds checksumming to another devsd device. gpl support could be done entirely outside the kernel. - erik
Re: [9fans] fossil caching venti errors
> AFAIK the disk is doing just fine. Moreover, even during the period when > fossil is complaining, venti/read on 9fs's score works just fine. So I > don't believe the fault is venti's. i don't believe that conclusion is warranted. /sys/src/cmd/fossil/cache.c:683,684 is where this condition gets set. so either the read fails or the score or length is bad. %r is not set (see a few lines down) so when combined with this report: > This is likely too large a hammer, but when this happens I rebuild the venti > index > so that I can get past the issue. I see this more under Plan 9 than p9p. The > block in error always exists in an arena and a checkarenas reports no errors. > The problem usually persists across reboots until I reconstitute the index. it's reasonable to guess that the block returned might not be the right one. in principle, this could be a drive failure, bad memory or a venti bug. i don't have a lot of venti experience, but i think this /sys/src/cmd/venti/srv/lump.c:226,230 is where venti reads and it seems to insure that the initial read double-checks scores. it would 1e-80 hard for a drive error to sneak by, so that leaves us with memory errors or venti cache bugs. it's hard to see how reindexing would fix a cache bug, though. so maybe i'm all wet. it would be interesting to know if the score of the block returned by venti/read is correct. - erik
Re: [9fans] fossil caching venti errors
sorry if this is a dupe. my original reply seems to have gone missing due to a local mishap. > venti/read should be doing this check automatically since libventi/client.c > builds with "int ventidoublechecksha1 = 1;" by default. yet you're reporting that fossil thinks the score does not match. this is a conundrum. either fossil is wrong or venti is. it would be good to have some data to help sort this out. - erik
[9fans] nupas dump results
the conversion of our last two big mail users to mail directories this week is quite interesting: Sun Mar 22 06:08:35: 126514 blocks copied to worm Sun Mar 29 06:01:55: 10922 blocks copied to worm that's a difference of ~900MB/day for two mailboxes. while we could easily sustain dumps of several gb/day, it's hard to argue that it's a good thing to have to cart all that useless data round. - erik
Re: [9fans] GSOC: Drawterm for the iPhone
> Legitimate iPhone apps can access the screen, camera, accelerometer, > gps and a portion of the filesystem. One could technically write a > drawterm that "polled" for instructions from a remote CPU server and > act on the local devices. > > Not sure if Apple would construe this as "executing remote code > fetched through a web service" - that's for a lawyer to discuss - but > technically speaking, it is *possible* to remotely control and receive > input from the iPhone screen, camera, accelerometer, gps etc; all > using the official SDK. seems like a risk not worth taking. i'd hate to have a project fail due to a forseeable problem. - erik
Re: [9fans] getting message need /sys/man/2/genrandom
> term% pull
> post...
> c sys/man/2/rand
> a sys/man/2/genrandom 664 sys sys 1196638940
> c 386/lib/ape/libap.a
> c sys/src/boot/pc/ether82563.c
> term% man genrandom
> need /sys/man/2/genrandom
> term% man genrandom
> need /sys/man/2/genrandom
that is very strange. "need $x" is printed
when test -f $x fails. this test is to guard
against the case where the man page exists
in the section index (/sys/man/?/INDEX)
but doesn't exist. test -f is false if
dirstat returns nil or the file is a directory.
unless of course, you /bin/test is something
different than /386/bin/test
sum /386/bin/test /bin/test
should produce two identicial lines.
on my system with ken's fs, there's no way
to make test -f false and be able to read the
index. perhaps there is some wierd mode
setting on fossil that makes this possible.
i think
ls -ld /sys/man/2^('' INDEX genrandom)
would likely provide the answer.
- erik
Re: [9fans] Visual font viewer
> On Mon, Mar 30, 2009 at 5:05 AM, Frederic Bonfanti > wrote: > > In May 2003, I did some tools to download ALL Unicode Glyphs (.gif), > > process them and create the relevent font files. > > > > The result is somehow ``ugly" :) although the only existing solution > > if you wanted to visualize any unicode glyph. > > I use fileformat.info to view Unicode blocks. being able to use the standard plan 9 tools right in an acme window is a great benefit to me. i did the same conversion of the unicode glyphs. i also use code2000 (contrib/install quanstro/code2000), which is good enough for most purposes and may look a little better. - erik
Re: [9fans] UTF and the preprocessor
others more qualified may disagree, but in this
case i think an enum would be preferred. however,
there are some cases where an enum will not do.
for example,
#define prγ(γ, fmt, ...) if(γ >1.) print(fmt, __VA_ARGS__)
i think that this patch will do the trick. i continued the
assumption that the the ctype macros are valid for any c,
even if !isascii(c). this diff is hard to read, the source is
also at http://www.quanstro.net/plan9/macbody
/n/dump/2009/0330/sys/src/cmd/cc/lex.c:1029,1035 - lex.c:1029,1035
} else
c = GETC();
for(;;) {
- if(!isspace(c))
+ if(c >= Runeself || !isspace(c))
return c;
if(c == '\n') {
lineno++;
; diffy -c macbody
/n/dump/2009/0330/sys/src/cmd/cc/macbody:18,39 - macbody:18,44
return n;
}
- Sym*
- getsym(void)
+ static void
+ nextsym(int c)
{
- int c;
+ int c1;
char *cp;
- c = getnsc();
- if(!isalpha(c) && c != '_') {
- unget(c);
- return S;
- }
for(cp = symb;;) {
- if(cp <= symb+NSYMB-4)
- *cp++ = c;
+ if(c >= Runeself) {
+ for(c1=0;;) {
+ if(cp <= symb+NSYMB-4)
+ cp[c1++] = c;
+ if(fullrune(cp, c1))
+ break;
+ c = getc();
+ }
+ cp += c1;
+ }else
+ if(cp <= symb+NSYMB-4)
+ *cp++ = c;
c = getc();
- if(isalnum(c) || c == '_')
+ if(c >= Runeself || isalnum(c) || c == '_')
continue;
unget(c);
break;
/n/dump/2009/0330/sys/src/cmd/cc/macbody:41,46 - macbody:46,64
*cp = 0;
if(cp > symb+NSYMB-4)
yyerror("symbol too large: %s", symb);
+ }
+
+ Sym*
+ getsym(void)
+ {
+ int c;
+
+ c = getnsc();
+ if(c < Runeself && !isalpha(c) && c != '_') {
+ unget(c);
+ return S;
+ }
+ nextsym(c);
return lookup();
}
/n/dump/2009/0330/sys/src/cmd/cc/macbody:193,199 - macbody:211,217
macdef(void)
{
Sym *s, *a;
- char *args[NARG], *np, *base;
+ char *args[NARG], *base;
int n, i, c, len, dots;
int ischr;
/n/dump/2009/0330/sys/src/cmd/cc/macbody:235,249 - macbody:253,261
len = 1;
ischr = 0;
for(;;) {
- if(isalpha(c) || c == '_') {
- np = symb;
- *np++ = c;
+ if(c >= Runeself || isalpha(c) || c == '_') {
+ nextsym(c);
c = getc();
- while(isalnum(c) || c == '_') {
- *np++ = c;
- c = getc();
- }
- *np = 0;
for(i=0; i= Runeself || !isspace(c))
bol = 0;
if(c == '\n')
bol = 1;
Re: [9fans] fossil caching venti errors
On Mon Mar 30 15:10:25 EDT 2009, lu...@proxima.alt.za wrote: > > never mind. i think it's not a sign of the problem we were discussing, > > but possibly something is simply down. > > Then the error message needs some tidying up. It happened to me too > and coincided with a total failure for "replica". Sigh! i submitted some changes to replica several years ago which should cause replica to abort when the remote fs has gone into casters up mode. the changes are worth considering if you depend on replica. normally, contrib/install quanstro/replica but also http://sources.coraid.com/sources/contrib/quanstro/replica/replica http://sources.coraid.com/sources/contrib/quanstro/root/sys/src/replica - erik
Re: [9fans] Latest pull killed my server
On Mon Mar 30 17:28:36 EDT 2009, vmh...@verizon.net wrote: > All - > I have been running an all-in-one server on a VMware server virtual > machine on my Windows laptop. > After executing a 'pull' this morning, the server crashed and I have not > been able to revive it. Fortunately it was a playground so little of > value is missing, but I thougt I should ask . . . > > I pulled down a copy of today's ISO and had the same results. It seems > to be panicking when hitting the (virtualized) Ethernet port. > > Anyone else seeing this? i am not seeing this, but sources venti is down and explains why pull stepped on important stuff. replica needs to be more defensive. regardless, that doesn't explain why the iso worked enough to get you to a panic. what is the panic message? - erik
Re: [9fans] Latest pull killed my server
/* compute log10(ether->mbps) into lg */
for(lg = 0, mb = ether->mbps; mb >= 10; lg++)
mb /= 10;
if (lg > 0)
lg--;
if (lg > 14)/* 2^(14+17) = 2ⁱ */
lg = 14;
/* allocate larger output queues for higher-speed interfaces */
bsz = 1UL << (lg + 17); /* 2ⁱ⁷ = 128K, bsz = 2ⁿ × 128K */
while (bsz > mainmem->maxsize / 8 && bsz > 128*1024)
bsz /= 2;
netifinit(ether, name, Ntypes, bsz);
>> while (ether->oq == nil && bsz > 128*1024) {
bsz /= 2;
ether->oq = qopen(bsz, Qmsg, 0, 0);
ether->limit = bsz;
}
if(ether->oq == nil)
panic("etherreset %s", name);
the simple fix would be to change the > on the marked
line to >=. but i think the while loop could be tossed
since malloc panics on failure and since qopen only allocates
sizeof(Queue) regardless of the limit argument. i had
this code when i wrote the myricom driver (qio sets q->limit itself).
j = ether->mbps;
if(j > 1000)
j *= 10;
for(i = 0; j >= 100; i++)
j /= 10;
i = (128oq = qopen(i, Qmsg, 0, 0);
if(ether->oq == nil)
panic("etherreset %s", name);
by the way, a quick scan shows
ether2114x
etherrhine
are capable of setting mbps to 0 on startup. this should
be legal, since ethernet can be connected after boot.
- erik
Re: [9fans] what features would you like in a shell?
On Tue Mar 31 11:37:06 EDT 2009, noagbodjivic...@gmail.com wrote: > hello, > > I'm a undergrade CS student doing a project for my introductory > operating systems class. my team wants to write a simple shell from > scratch. > > one idea we have found so far is the following. the shell will record > all the programs it has run. whenever a program goes awry and is > killed by the kernel. the shell will reload it. unfortunately, the most common reason for a program to go arwy is that the program is broken and it will break again when reloated. it would be more interesting to explore how a shell in plan 9 could be used to build simple fs. rc has a very interesting virtual machine. it might be interesting to build a shell with some hooks into its vm. paul haahr and byron built a shell with scheme-y internals and exposed them. interesting, but complicated. it would be interesting to use something closer to regular expressions rather than standard shell globbing. the challenge would be to avoid gratuitous breakage and yet allow the match operator to be much more powerful. these are areas where rc might be improved upon. however, as per usual, it was hard to improve on bourne, and it's even harder to improve on duff. nevertheless, i learned quite a bit from failing to improve on rc. - erik
Re: [9fans] what features would you like in a shell?
> I'd love to see tab completion at the command line. If there is a way to do > it in Plan 9, then I haven't figured it out yet. But then I'm a newby to the > OS. it's done by rio, not the shell and you use the insert key, not tab, as god intended. bash irritates the heck out of me when it won't let me type a tab. it's a gentle reminder that i should stop wasting time on linux. - erik
Re: [9fans] drawterm crash
On Tue Mar 31 12:14:49 EDT 2009, uai...@gmail.com wrote: > Hi, > Just try to paste anything coming from X. (e.g. paint some text from > an xterm, then try to paste it on some terminal on drawterm, using the > menu or the 1-3 mouse chord, both crash anyway) you're using a 64-bit os, aren't you? if that's the case, i fixed this a week or so ago and pushed the patch to russ. i think he's got the fix. if not, just fix the compile warning and you'll be good-to-go. it's an int vs. long issue. unfortunately, i don't have yesterday for linux and don't remember what i fixed. - erik
Re: [9fans] what features would you like in a shell?
> I've not run into many actual problems with rc so it's pretty near
> perfect :>
pretty near.
redirection has a few rough points. dealing with a device
that expects a write then a read like /net/dns is painful.
i can never get the syntax right the first try.
and (hopefully this isn't just my ignorance) i don't know how
to open a fd to a background shell as one would in bourne.
quoting can get a little dicy when combined with here
docs.
> hash maps : a['name'] = 'glenda'
> arithmetic - though with the 80/20 rule, I don't think the bloat is worth it
the shell i worked on had regular lists, not flat
lists like rc. the problem with this is that suppose
you're in a directory with a.c b.c a.h b.h. does this
print 2 or 4?
fn x {
echo $#*
}
x *.c *.h
in rc, the answer is obvious. if you allow regular
lists, then * is either ((a.c b.c) (a.h b.h)) or
(a.c b.c a.h b.h).
perhaps i just missed the obvious.
- erik
Re: [9fans] what features would you like in a shell?
> it's done by rio, not the shell and you use the > insert key, not tab, as god intended. bash insert ≡ control-f. - erik
Re: [9fans] what features would you like in a shell?
> thanks a lot for the reply. i got my hand of the unix programming > environment by Kernighan and Pike. I don't think we have the > programming skills for implementing a regular expression engine, but i would recommend against reimplementing regular expressions. ken is hard to beat; the standard regexp library is what you want. the trick is going to be thinking hard about how you are going to deal with some of the mismatches between standard regular expressions and file names. for example, you might need to deal with the fact that '.' is common in file names, but means any character in a regular expression. i think this is going to be the cannonical problem: globregexp *.[ch] \.[ch]$ '*' \* (this problem is easy) i don't think this one is about writing lots of code. > you think the idea of reloading a crashed program is not a good one? i don't like the idea. > for example, what if it's a web browser? how do you determine when to relaunch? how do you decide that the program is not going to relaunch? how do you stop an errant shell from relaunching and consuming all your resources? - erik
Re: [9fans] what features would you like in a shell?
> re not reinventing the wheel, you might want to look into the es
> shell. I think this is what erik alluded to earlier - I've never used
> it myself but I understand it is extremely programmable, to the point
> where you can redefine the pipe operator for example.
; %pipe {echo true} 1 0 cat
true
; fn %pipe {echo $* ; $&pipe $*}; echo fu | cat
{echo fu} 1 0 {cat}
fu
- erik
Re: [9fans] outside the gsoc2009
On Thu Apr 2 06:41:06 EDT 2009, uai...@gmail.com wrote: > Sadly for me, I found out that I do not qualify as a student (I > thought I did, but I don't). > Anyway, I've seen some interesting ideas for plan 9 and inferno, most > of them out of my reach. But I think some of them are easy enough for > me to try them (hope so!). > So I would like to give it a try to the Instant Messaging filesystem > (IMFS) for plan 9 or a simple game for inferno. It is clear that I > mean to work on one of these things if nobody gets it for the gsoc. > And if someone does get them, I would be interested to work on one > project of low to medium difficulty that is available. if you do a server as well, i'd be able to put it to use. - erik
[9fans] ahci irq bug
in belated regression testing, i found that i introduced a
bug in ahci when fixing hbas with a sparse pi register.
(it's possible to have a non-contiguous set of available ports.
this is often the case on last-generation laptops.)
the symptom is that drives on the highest-numbered port
never see interrupts. the simplist change is to replace
/n/sources/plan9/sys/src/9/pc/sdiahci.c:1925
c->mport = c->hba->cap & ((1<<5)-1);
with
c->mport = (c->hba->cap & 0x1f) + 1;
however it's not entirely clear from the ahci 0.99—1.3 standards
that with sparse ports, that the highest bit set in the pi
register is < (c->hba->cap & 0x1f) + 1, though that's implied.
dodging this problem results in a more robust and efficient interrupt
routine (the only place where mport is used), so i think a
better but slightly bigger change is to get rid of c->mport
entirely and change (>)/add (+) these two lines:
static void
iainterrupt(Ureg*, void *a)
{
int i;
ulong cause, m;
Ctlr *c;
Drive *d;
c = a;
ilock(c);
cause = c->hba->isr;
> for(i = 0; cause; i++){
m = 1 << i;
if((cause & m) == 0)
continue;
+ cause &= ~m;
this was the change i made in the contrib packages
quanstro/sd and quanstro/9load-e820.
- erik
Re: [9fans] Virtual PC + Win64 = i/o errors
> fossil(#S/sdC0/fossil)...version...time... > command 30 > data f0caaaf8 limit f0cab8f8 dlen 8291 status 0 error 0 > lba 605536 -> 605536, count 16 -> 16 (16) > 0x00 0x06 0x6A 0x3D 0x09 0xE0 0x58 > 0x40: E307 0x42: Cx48: 00 > 0x4A: > fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x5529: date Sun Apr > 5 > 06:37:19 PDT 2009 > part=data block 21801: i/o error did you type in this by hand? i'm wondering about the "dlen = 8291". that should be 8192. the device driver claims you owe him data after doing 10 sectors. but you would have given him another sector, had you gotten an interrupt. so the question is, why did you get the first 9 interrupts and not get the 10th? §9.1 #4 p. 64, ata 7 vol 2 says it should, but if you read a little further it can deassert the interrupt if the command register is written. it's really hard to say anything useful without seeing this problem up close. a rather desperate guess might be that this is a pio timing thing. (note that this is presented as an intel pci ide chipset. there must be a reason those registers are printed out for intel parts.) if it is, then dma mode from the get-go could fix the problem. is this an ahci-capable chipset? or is virtual pc presenting something odd? - erik
Re: [9fans] Stuck at partdisk
> Except that it's now looking to take about 5 hours to install on my 3 > core AMD64 box with 8GB RAM :) that's no dma problem. - erik
Re: [9fans] typed sh (was: what features would you like in a shell?)
> Nitpick: the output type of one command and the input type of > the next command in the pipeline has to match, not every > command. i think this is wrong. there's no requirement that the programs participating in a pipeline are compatable at all; that's the beauty of pipes. you can do things that were not envisioned at the time the programs were written. > To go beyond simple char streams, one can for example build a > s-expr pipeline: a stream of self identifying objects of a > few types (chars, numbers, symbols, lists, vectors). In Q > (from kx.com) over an IPC connection you can send strings, > vectors, dictionaries, tables, or arbitray Q expressions. But > there the model is more of a client/server. or ntfs where files are databases. not sure if streams can look the same way. - erik
Re: [9fans] double click selects a word
> is there any good reason for a double click (in rio, sam, acme, ...) > to select a word (probably) defined by sth. like > /[a-zA-Z0-9_]+/ > and not sth. white-space delimited instead? > Double clicking e.g. on 'text.txt' only selects 'text' or 'txt', while > one usually wants the whole. The same with absolute paths like > '/usr/ruda/lib/profile', etc. In linux a double-click usually > highlights the whole and usually this is what I want. acme is for programming. the existing behavior is much better for programming where strings are generally delimited by ". - erik
Re: [9fans] Virtual PC + Win64 = i/o errors
> How exactly would I enable that on an already-installed VM? > Would a modified plan9.ini on a floppy > image do the trick? unfortunately, there's no *justusedma=1 plan9.ini option. that would be far to easy. i think you will need to modify the kernel to make progress. do you have a way of compiling kernels? or at least sticking a new kernel into 9fat? - erik
Re: [9fans] typed sh (was: what features would you like in a shell?)
> If program A outputs numbers in big-endian order and B > expects input in little-endian order, A|B won't do the "right > thing". non-marshaled data considered harmful. film at 11. ☺ what i said was not that A|B "makes sense" for all A and B and for any data but rather that using text streams makes A|B possible for any A and any B and any input. the output might not be useful, but that is a problem on a completely different semantic level, one that computers are usually no good at. alsi, i don't think that "type compatability" is sufficient to insure that the output "makes sense". what if A produces big-endian times in ms while B expects big-endian times in µs. > Even for programs like wc have a concept of a > 'character' and if the prev prog. produces something else you > will be counting something meaningless. that's why plan 9 uses a single character set. but forcing compability seems worse. where are these decisions centralized? how do you change decisions? can you override these decisions (cast)? how does the output of, say, awk get typed? - erik
Re: [9fans] typed sh
> > but rather that using text streams makes > > A|B possible for any A and any B and any input. > What is this "text" of which you speak ? ASCII EBCDIC UTF-16 UTF-8 > ISO8859 etc. etc. etc. there's got to be a latin term parallel to reducto ad absurdum that means the opposite. make the problem gratituiously harder until no sensible statements can be made at all. or maybe it's the opposite of divide and conquer. accrete and be subjugated? ☺. by the way, tcs works fine for me. - erik
Re: [9fans] Virtual PC + Win64 = i/o errors
> fossil(#S/sdC0/fossil)...version...time... > command 30 > data f0caaaf8 limit f0cab8f8 dlen 8291 status 0 error 0 > lba 605536 -> 605536, count 16 -> 16 (16) > 0x00 0x06 0x6A 0x3D 0x09 0xE0 0x58 > 0x40: E307 0x42: Cx48: 00 > 0x4A: > fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x5529: date Sun Apr > 5 > 06:37:19 PDT 2009 > part=data block 21801: i/o error many thanks to bhuntsman for having the patience to put up with my crappy code. it turns out that this is due to some poor timing on the part of virtual pc. virtual pc asserts an interrupt while the virtual controller is busy. then virtual pc refuses to reassert the interrupt, though the condition is not handled. this problem only hapens in pio mode. (it just occurs to me in writing this up that i had not considered that this might be an edge vs. level irq problem. and i'm ignorant enough of virtual pc to not even know if that's a stupid idea or not.) in any event, replacing the big tsleep with a loop of smaller tsleeps and checking for missed irqs seems to help pio commands. i also added a kernel variable to plan9.ini, sdXXdma=on. that might be overkill, but i was worried about fossil/venti needing to do a lot of disasterously slow i/o before cpurc/termrc gets a chance to run. i'd like to hear if anyone finds that this is necessary. one thing that is not yet done is a similar approach with packet io. i'd like to test it with actual hardware rather than guessing. what i've got so far is on sources in the contrib package quanstro/sd. i'd like to hear if this works (or doesn't) for anybody else. - erik
Re: [9fans] a bit OT, programming style question
> Would there be any merit to breaking the shell apart into a number of > smaller programs? Looking at GNU bash as an example (though I know GNU > is probably one of the worst places to look for "Unix style"), It is my > understanding that one program handles many things, such as keyboard > bindings (which I believe in turn requires bash to read in cbreak or raw > or whatever and do it's own line editing), glob expansion, aliases, > history, syntax parsing, command execution, job control, etc. etc. > > IMO this results in a more complex program than necessary. Keyboard > bindings for example; why couldn't they be handled by a program that > just does keyboard bindings + line editing, and writes finalized lines > to the shell. This in turn could also allow bindings to be more easily > customized (such as binding autocomplete to Ctrl+F instead of tab) > depending on its implementation. fwiw, plan 9 handles key bindings in #κ. the shell hasn't a clue. rio (or acme) handles the editing. again, the shell hasn't a clue. and autocomplete? yup. same story. hapless rc hasn't a clue. rc is proof that ignorance is bliss. - erik
[9fans] self inflicted gunshot wound
like kutner, the plumber decided to off itself for seemingly inscrutable reasons this morning. the abort condition does not appear to hold: if(t > s+n) abort(); since 0x3a497 < 0x3a430+0x93 and also a!= nil, as would be required. the interesting thing that happened at the time was that one of plumber's clients was off in the weeds waiting for something to happen. ideas? - erik abort()+0x0 /sys/src/libc/9sys/abort.c:6 plumbpackattr(attr=0x28b00)+0x126 /sys/src/libplumb/mesg.c:125 n=0x93 a=0x3e990 s=0x3a430 t=0x3a497 plumbpack(m=0x3c710,np=0x3e7c4)+0x31 /sys/src/libplumb/mesg.c:148 ndata=0x10 attr=0x6523 n=0x1430 buf=0x0 p=0x3a330 drainqueue(d=0x1b288)+0x84 /sys/src/cmd/plumb/fsys.c:393 prevs=0x0 nexts=0x3eb30 prevr=0x0 i=0x0 r=0x3a330 s=0x3e7b0 n=0x103cb fsysread(buf=0x28f50,f=0x3c210,t=0x3a1f0)+0x1ed /sys/src/cmd/plumb/fsys.c:811 o=0x17 e=0x0 clock=0x3a1f0 b=0x3c210 i=0x13 d=0x1a7f n=0x1f494 fsysproc()+0x186 /sys/src/cmd/plumb/fsys.c:262 t=0x3a1f0 buf=0x28f50 n=0x17 acid: regs() PC 0xc80c abort /sys/src/libc/9sys/abort.c:6 SP 0x00068e78 ECODE 0x0004 EFLAG 0x0206 CS 0x0023 DS0x001b SS 0x001b GS 0x001b FS0x001b ES 0x001b TRAP0x000e page fault AX 0x0003a4c3 BX 0x0003a4c6 CX 0x0003a430 DX 0x0093 DI 0x0003a4c7 SI 0x0003ea19 BP 0x0003e9f0 acid: stacks() p=(Proc)0x3f090pid 4505 Sched t=(Thread)0x40f10Rendez /sys/src/cmd/plumb/fsys.c:295 newfid _threadrendezvous(tag=0x1939c,val=0x1)+0x11d /sys/src/libthread/rendez.c:56 qlock(q=0x1f448)+0x6f /sys/src/libc/9sys/qlock.c:74 newfid(fid=0x30d)+0x10 /sys/src/cmd/plumb/fsys.c:295 fsysproc()+0x165 /sys/src/cmd/plumb/fsys.c:261 launcher386(arg=0x0,f=0x17f6)+0x10 /sys/src/libthread/386.c:10 0xfefefefe ?file?:0 p=(Proc)0x3c750pid 4506 Sched t=(Thread)0x3be30Rendez /sys/src/cmd/plumb/fsys.c:529 dispose _threadrendezvous(tag=0x19390,val=0x1)+0x11d /sys/src/libthread/rendez.c:56 qlock(q=0x1f448)+0x6f /sys/src/libc/9sys/qlock.c:74 dispose(rs=0x0,m=0x39a70,e=0x0,t=0x28bc0,buf=0x68ff0)+0x10 /sys/src/cmd/plumb/fsys.c:529 fsyswrite(buf=0x68ff0,f=0x3c270,t=0x28bc0)+0x1ef /sys/src/cmd/plumb/fsys.c:898 fsysproc()+0x186 /sys/src/cmd/plumb/fsys.c:262 launcher386(arg=0x0,f=0x17f6)+0x10 /sys/src/libthread/386.c:10 0xfefefefe ?file?:0 p=(Proc)0x39010pid 16359 Running t=(Thread)0x287a0Running/sys/src/libplumb/mesg.c:125 plumbpackattr abort()+0x0 /sys/src/libc/9sys/abort.c:6 plumbpackattr(attr=0x28b00)+0x126 /sys/src/libplumb/mesg.c:125 plumbpack(m=0x3c710,np=0x3e7c4)+0x31 /sys/src/libplumb/mesg.c:148 drainqueue(d=0x1b288)+0x84 /sys/src/cmd/plumb/fsys.c:393 fsysread(buf=0x28f50,f=0x3c210,t=0x3a1f0)+0x1ed /sys/src/cmd/plumb/fsys.c:811 fsysproc()+0x186 /sys/src/cmd/plumb/fsys.c:262 launcher386(arg=0x0,f=0x17f6)+0x10 /sys/src/libthread/386.c:10 0xfefefefe ?file?:0 p=(Proc)0x6b030pid 83108 Running t=(Thread)0x39f50Running/sys/src/cmd/plumb/fsys.c:241 fsysproc pread()+0x7 /sys/src/libc/9syscall/pread.s:5 read(fd=0x6,buf=0x6d9f0,n=0x4)+0x2f /sys/src/libc/9sys/read.c:7 readn(n=0x4,av=0x6d9f0,f=0x6)+0x3a /sys/src/libc/port/readn.c:13 read9pmsg(abuf=0x6d9f0,fd=0x6,n=0x2018)+0x24 /sys/src/libc/9sys/read9pmsg.c:14 fsysproc()+0x74 /sys/src/cmd/plumb/fsys.c:241 launcher386(arg=0x0,f=0x17f6)+0x10 /sys/src/libthread/386.c:10 0xfefefefe ?file?:0
Re: [9fans] a bit OT, programming style question
> > Exactly, and the end user can choose to have a re or glob expansion > > program, rather than having to muck up the shell code with different > > flags or whatever. > > somebody is going to jump in very soon and tell us why this is funny :-) i promised i wouldn't, - erik
Re: [9fans] a bit OT, programming style question
> Well someone's gotta tell these prepubescents ... > > "Because the V6 shell did it, that's why.". ooh. ooh. i know what you're going to say next: if should be an external program. - erik
Re: [9fans] a bit OT, programming style question
> A bad implementation is not a bad design. neither is stink an outhouse, but often they keep company. - erik
Re: [9fans] self inflicted gunshot wound
On Tue Apr 7 21:50:14 EDT 2009, r...@swtch.com wrote: > > abort()+0x0 /sys/src/libc/9sys/abort.c:6 > > plumbpackattr(attr=0x28b00)+0x126 /sys/src/libplumb/mesg.c:125 > >n=0x93 > >a=0x3e990 > >s=0x3a430 > >t=0x3a497 > > t is unlikely to be correct here; it would have been saved > at the last call to strlen but since then got +='ed with the result. > > > acid: regs() > > PC 0xc80c abort /sys/src/libc/9sys/abort.c:6 > > SP 0x00068e78 ECODE 0x0004 EFLAG 0x0206 > > CS 0x0023 DS0x001b SS 0x001b > > GS 0x001b FS0x001b ES 0x001b > > TRAP0x000e page fault > > AX 0x0003a4c3 BX 0x0003a4c6 CX 0x0003a430 DX 0x0093 > > DI 0x0003a4c7 SI 0x0003ea19 BP 0x0003e9f0 > > there's s+n in AX. t is likely to be BX or DI, judging from the > pointer values; it has either written 3 or 4 bytes past the > end of the allocated section, which explains the abort. > you'd have to disassemble plumbpackattr to make sure. > it would be interesting to print *(*plumbpackattr:s\s) > to see if the string is corrupted. acid: *(*plumbpackattr:s\s) filetype=mail sender=x...@.xxx length=8749 mailtype=delete date='Sun Mar4de7153cecd4a9b45aead1clfs digest=aff98fb56526d94ab768adbc93d12d989a11ed53 hmmm. i think you might be on to something after all. maybe it was fratricide. > i don't understand what you mean. > plumbers clients are always waiting for something > to happen. the plumber's only job is to tell them > when it does. several were waiting on something else to happen; they were sleeping waiting for an exclusive-open file. the only reason i mentioned it is that may have been 5 minutes between the time that plumber tried to write the message and when it could be delivered. > i suspect the global buffer in plumbpackattr's quote. > if you had multiple threads running through > plumbpackattr at once, it might cause the kind of crash you saw. > all the ordinary plumbing is protected by the QLock named queue, > but it looks like maybe if you'd been writing the rules file > at exactly the same time, that might have triggered > a simultaneous plumbpackattr call. unfortunately, i was not writing the rules file, that i know of. - erik
Re: [9fans] self inflicted gunshot wound
> i would put a lock around the use of attrbuf > in both plumbpackattr and plumbunpackattr. > > russ why not just use malloc? - erik
[9fans] for rsc -- mail failure. sorry.
Your request ``smtp /net.alt/tcp!swtch.com rsc '' failed (code smtp 89792: Permanent Failure). The symptom was: Tue Apr 7 23:47:42 EDT 2009 connect to /net.alt/tcp!swtch.com: 550 relaying denied - erik
[9fans] new memdraw troubles
the attached image does lots of funny things. mug (which probablly can't handle the image) displays an image striped in the bottom half. it's all black with a varying α, but displays all black in faces with the new draw code, but blue with the old (drawterm) code. togif makes it blue again on plan 9 and under xv. i haven't yet made much progress with this one. - erikfrom postmas...@brasstown: 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: plan 9 image Content-Disposition: attachment; filename=quanstro.net.1 Content-Transfer-Encoding: base64 quanstro.net.1.suspect Description: Binary data
Re: [9fans] Is this Plan9 performance, Ok
On Thu Apr 9 05:18:31 EDT 2009, bdhee...@gmail.com wrote: > Extraction of only a 180M archive knelled down a 1.8Ghz/P-M4/i686/1Gb > RAM/40GiB IDE HDD machine running vanilla Plan9 installed natively: > > term% cat /dev/sdC0/ctl |grep dma > config 0040 capabilities 2F00 dma 00550020 dmactl 00550020 rwm 8 rwmctl 0 > term% time /n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 > ... > 183.27u 31.06s 623.86r tar zxf > /n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 > term% ls -l /n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 > --rw-rw-r-- M 47 root wheel 188569960 Apr 8 16:15 a laptop drive of that general description is probablly good for 20mb/s sequential io. assuming that the uncompressed archive is 3x larger, you're getting about 1mb/s writes even with the slow decompression. it looks like that archive is pulled over the network. since you have a 3c905, that would be at a maximum of about 10mb/s. if you're linked at 10mb/s, the limit is about 1mb/s. i'd recommend checking the drive's speed with dd. time dd -if /dev/sdC0/data -of /dev/null -count 5000 -bs 64k i don't recall if the 3c905 will tell you its link speed. you can try /dev/kmesg or /net/ether0/ifstats under mbps. the latter may be the maximum mbps the card is capable of, due to the fact mbps is used to size queues. i like the suggestion to time pulling down the archive and sending it to /dev/null. since you have enough memory. you could seperately time extracting it to ramfs. > Moreover, it is strange that Plan9 running under QEMU on 2.4Ghz/Core2 > Duo/2Gb RAM/250GiB SATA/IDE HDD machine out performs a natively > installed one. what is slower, exactly? - erik
Re: [9fans] a bit OT, programming style question
On Thu Apr 9 10:48:08 EDT 2009, eris.discor...@gmail.com wrote: > Most of it in the 19 lines for one TERMCAP variable. Strictly a relic of > the past kept with all good intentions: backward compatibility, and heeding [...] > Quite a considerable portion of UNIX-like systems, FreeBSD in this case, is > the way it is not because the developers are stupid, rather because they > have a "constituency" to tend to. They aren't carefree researchers with > high ambitions. this is the "space-shuttle dichotomy." it's a false one. it's a continuum. its ends are dangerous. on the one hand, if you change things, the new things are likely to be buggy. on the space shuttle, this is bad. people die. on the other hand, systems are not perfect. and if the problems are not addressed, eventually the system will need to much fixing and will be abandoned. yet bringing a new system on line is an even bigger risk. everything is new simultaneously. it is interesting to me that some software manages to run off both ends of this continuum at the same time. in linux your termcap from 1981 will still work, but software written to access /sys last year is likely out-of-date. your insinuation that *bsd is a real serious system and plan 9 is a research system doesn't make any historical sense to me. they both started as research systems. i am not aware of any law that prevents a system that started as a research project from becoming a serious production system. i know of many thousands of plan 9 systems in production right now. - erik
Re: [9fans] extensions of "interest"
On Thu Apr 9 13:19:11 EDT 2009, rminn...@gmail.com wrote: > www.pdl.cmu.edu/posix > > statlite() the statlite man page is itself lightweight, being available on the web in pdf form. - erik
Re: [9fans] extensions of "interest"
On Thu Apr 9 13:44:50 EDT 2009, mirtchov...@gmail.com wrote: > i propose an extension to HTTP (call it HTTPeeLite) which allows me to > specify in my request to that webpage the format in which i prefer to > receive the man page. a 'setup' exchange can be sent beforehand to > establish the available types of documentation (.doc, .pdf, .tex, > .rtf, etc). or you could refrain from making the web any worse by just providing the document in ... oh, what's that archane format ... right, html. if i recall correctly, it's the standard for web content. ☺ by the way, this is an absolute gem from sutoc "handles are not inherently portable. however, between like architechtures and software operating system support versions things just might work out. fills me with optimism. - erik
Re: [9fans] extensions of "interest"
> On Thu, Apr 9, 2009 at 1:25 PM, erik quanstrom wrote: > > On Thu Apr 9 13:19:11 EDT 2009, rminn...@gmail.com wrote: > >> www.pdl.cmu.edu/posix > >> > >> statlite() > > > > the statlite man page is itself lightweight, being available > > on the web in pdf form. > > And MS doc! There's a common Unix-y file format. although statlite seems impossible to use, it's by no means the most troublesome syscall suggested. check out openg and sutoc. kernel file handles? by the way, it's a long time since i've seen a precidence bug in a man page, but openg manages. see p. 7 of openg linked from the same page. - erik
Re: [9fans] extensions of "interest"
> > Already part of HTTP > > > > Accept: application/msword; q=1, application/pdf; > > q=0.5,application/x-troff-ms; q=0.3 > > > > q is the level of preference, you'll get word docs first > > > > > > Wow. Could it get any worse? yes. just read a few lines further in the rfc and note that there's also a "level" modifier. it's not clear to me what level is supposed to do from their example. Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5 - erik
Re: [9fans] a bit OT, programming style question
> $ set | wc -l > 64 > > I don't quite get that locally. please upgrade your distribution. - erik
