Re: [9fans] Xen 3.1 w/ Plan 9 domU: plan9.img file after install not
Please google lguest and see what you think. It's 5K lines of code, the guest support code is trivial, and I think overall this is going to be the easiest thing to do. I've just had a quick browse through (the patch is actually 8977 lines, but maybe the 5k doesn't include comments). My first impression is that's more like it. Way simpler. But: - Does some of the simplicity come from being linux-specific? Comments say guest and host run the same kernel. Or is it generic enough to work with Plan 9 too? - My interest in Xen is pragmatic: there are plenty of hosting companies offering virtual servers based on Xen, and some at least are happy to let you run a Plan 9 guest kernel. (In particular I can recommend http://www.blackcatnetworks.co.uk from personal experience.) How long before lguest reaches that level of maturity? Sadly, simplicity in itself is not much of a marketing advantage in the real world. -- Richard
[9fans] Mailing list archive.
http://www.bx.psu.edu/~schwartz/9fans/9fans.mbox.txt seems to have stopped updating on the 8th of June. If at all possible to restart it, can we remove the blank line at the beginning that invalidates it to all mailer readers I'm familiar with? ++L
Re: [9fans] Xen 3.1 w/ Plan 9 domU: plan9.img file after install not
On 7/6/07, Richard Miller [EMAIL PROTECTED] wrote: - Does some of the simplicity come from being linux-specific? Comments say guest and host run the same kernel. Or is it generic enough to work with Plan 9 too? it's working up to me calling LHINIT and then LHCRASH. - My interest in Xen is pragmatic: there are plenty of hosting companies offering virtual servers based on Xen, and some at least are happy to let you run a Plan 9 guest kernel. (In particular I can recommend http://www.blackcatnetworks.co.uk from personal experience.) How long before lguest reaches that level of maturity? Sadly, simplicity in itself is not much of a marketing advantage in the real world. Ah, so keeping a xen port is good. That's fine. But for THX, Xen is just too hard. ron
Re: [9fans] implementing 9p read
This probably also means that Read returns in most cases less bytes than requested, just as much as needed for the current line up to \n. The server likely has to keep some information like the next read-offset expected, and the next line number, so that it can check whether the next read-request actually asks for the next line -- if it doesn't ignore seek/offsets at all, which also seems practicable. You cannot do this, the usual idiom is that if read returns less than the app expected this is treated as EOF. in my library the low level function generates line at a time data, the library then performs multiple reads to satisfy the apps read request filling its buffer and rembembering the partial line for the next read request. I suppose this is adequate for control files waiting for commands. One can leave the fd open, and send one line after the other as needed. I don't generally find this is nescessary, the fileserver/device driver holds internal state so multiple writes mearly modify this state, thusly: echo 'cts=1' /dev/uart/ctl echo 'baud=115200' /dev/uart/ctl We get a real win using the everything is a file idea in embedded as most of our products contain multiple PCBs and each PCB has a CPU (to load its xilinxes if nothing else). Given the remote file protocol running over a a couple of wires (the link layer distantly related to datakit) we can monitor any cpu from any other cpu and upgrade all flash files from the cpu that has ethernet. Its a shame that we didn't have the guts and skill to make it real plan9 from the begining - hindsignt is a wonderful thing. -Steve
Re: [9fans] implementing 9p read
You cannot do this, the usual idiom is that if read returns less than the app expected this is treated as EOF. in my library the low level a write that returns less than was written is trouble, but end-of-file is a read returning zero. the count returned by read can be less than the amount requested without marking end-of-file (eg, reads on a pipe or network connection). that's why readn exists.
Re: [9fans] implementing 9p read
On 7/6/07, Steve Simon [EMAIL PROTECTED] wrote: You cannot do this, the usual idiom is that if read returns less than the app expected this is treated as EOF. Oh not, that's not at all true. Any program that behaves this way is broken. Unless I totally misunderstand your point. ron
Re: [9fans] Xen 3.1 w/ Plan 9 domU: plan9.img file after install not
it's working up to me calling LHINIT and then LHCRASH. Now that's what I call minimalist.
[9fans] General Question: 9fans.mbox archive and problem solving w/computers
Just thinking about this probably fairly simple task, but it seems a bit overwhelming. Suppose you want a searchable archive of 9fans and all you have to start with is this single 150 MB file of ~46,000 messages. What do you do? The answer isn't obvious to me. Greg P.S. I'm prepared to rely on existing searchable archives to do this in real life. It's just that in the few minutes thought I've given to this problem, I've become much more impressed with those existing seachable archives and their very quick responses.
Re: [9fans] General Question: 9fans.mbox archive and problem solving w/computers
most machines these days have 10x that much memory. it should be speedy enough to use strstr(2) once you've loaded them into memory. and even loading them into memory should take no more than a few seconds at 80MB/s. a more elegant solution would be to reduce each document to a set of stemmed words, enumerate the set of all stems in all documents and create a bit array mapping stems to message #. but that seems like too much work for only 150MB. - erik
[9fans] so, what could this one be?
I'm flummoxed. Poleaxed even. (2830) DATAinitcode+2(SB)/1,$1 _strayintrx: multiple initialization (2830) DATAinitcode+3(SB)/1,$235 _strayintrx: multiple initialization (2830) DATAinitcode+6(SB)/1,$1 _strayintrx: multiple initialization (2830) DATAinitcode+7(SB)/1,$10 _strayintrx: multiple initialization (2830) DATAinitcode+11(SB)/1,$60 _strayintrx: multiple initialization (2831) DATAinitcode+22(SB)/1,$16 _strayintrx: multiple initialization (2831) DATAinitcode+23(SB)/1,$32 _strayintrx: multiple initialization (2832) DATAinitcode+32(SB)/1,$131 _strayintrx: multiple initialization (2832) DATAinitcode+33(SB)/1,$236 _strayintrx: multiple initialization (2832) DATAinitcode+34(SB)/1,$12 _strayintrx: multiple initialization (2832) DATAinitcode+35(SB)/1,$139 _strayintrx: multiple initialization (2832) DATAinitcode+36(SB)/1,$68 _strayintrx: multiple initialization (2832) DATAinitcode+37(SB)/1,$36 _strayintrx: multiple initialization (2832) DATAinitcode+38(SB)/1,$16 _strayintrx: multiple initialization (2832) DATAinitcode+39(SB)/1,$137 _strayintrx: multiple initialization (2832) DATAinitcode+40(SB)/1,$4 _strayintrx: multiple initialization (2832) DATAinitcode+41(SB)/1,$36 _strayintrx: multiple initialization (2832) DATAinitcode+42(SB)/1,$141 _strayintrx: multiple initialization (2832) DATAinitcode+43(SB)/1,$68 _strayintrx: multiple initialization (2832) DATAinitcode+44(SB)/1,$36 _strayintrx: multiple initialization (2832) DATAinitcode+45(SB)/1,$16 _strayintrx: multiple initialization too many errors What the heck is this? Whatever it is, it seems unrelated to the error message. ron
[9fans] Re: so, what could this one be?
On 7/6/07, ron minnich [EMAIL PROTECTED] wrote: I'm flummoxed. Poleaxed even. (2830) DATAinitcode+2(SB)/1,$1 _strayintrx: multiple initialization Never mind, found it. Don't cut and paste and include init.h twice. (init.h is C code ...) ron
Re: [9fans] Mailing list archive.
On Fri, Jul 06, 2007 at 03:35:36PM +0200, Lucio De Re wrote: http://www.bx.psu.edu/~schwartz/9fans/9fans.mbox.txt seems to have stopped updating on the 8th of June. If at all possible to restart it, can we remove the blank line at the beginning that invalidates it to all mailer readers I'm familiar with? I'll fix it. It looks like my crontab got nuked during an upgrade of some sort.
Re: [9fans] implementing 9p read
You cannot do this, the usual idiom is that if read returns less than the app expected this is treated as EOF. Oh not, that's not at all true. Any program that behaves this way is broken. Unless I totally misunderstand your point. Ok, You are probably right, its an assumption I have seen in code in the past, though not in plan9: while((n = fread(buf, 1, sizeof(buf), fp)) != sizeof(buf)) if(fwrite(buf, 1, n, out) != n) sysfatal(write failed); I have always tried to code defensively around it when writing fileservers by returning full buffers, it seems I have been fleeing a mere spectre. -Steve
Re: [9fans] implementing 9p read
while((n = fread(buf, 1, sizeof(buf), fp)) != sizeof(buf)) if(fwrite(buf, 1, n, out) != n) sysfatal(write failed); fread is buffered, or similar to readn, and does all it can, hence the difference from plain read
