Re: [9fans] drawterm dies when my mac book sleeps by 9p design?
// I can't rememberif he actually called them an // abomination, but at the same time, onewas left // with the feeling that he might have. Geoff's explanation to me a long time ago wasn't quite as emotional, but was quite helpful for understanding what was actually going on: They're not 'keep alives'. They're 'make deads'.
Re: [9fans] realemu update
the /dev/realmode intraface was not documented, but it is very simple.
/dev/realmodemem is just an image of the first megabyte of
physical memory that is addressable from 16 bit realmode.
plan9 reserves a 4k page at 0x9000 (defined as RMBUF) that can be
refered to in the bios call as data buffer. previously, this was the
only offset range that could be written with /dev/realmodemem.
in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h)
(in x86 machine byte order?) containing the register contents and the
interrupt number of the bios call you want to make.
the write returns when the BIOS call returns and the machine
state can be read back from /dev/realmode.
realemu did a little extension to the interface: it allows reading and
writing the whole address space and in case the trap is zero in the
Ureg, it will copy ss, sp, cs, and pc in the virtual cpu state too and not
make a BIOS interrupt. this is used by loadcom.c to run dos .com
files in the emulator.
8i was never in a working or finished state... it was able to execute
the modeinfo vbe calls on my t23 (after changing the KZERO offset) but
that was about it. there are not many similarities with 8i anymore.
i worked on 8i for a while... debugging 8i gave me a good overview of
whats needed for 80x86 interpretation so after some time i started
over from scratch as i had to look in the intel docs for every
instruction anyway to figure out whats wrong, so why not just look at
opcode details of opcodes being actually in use... i borrowed optab
decode tables and the general structure from 8i but the rest is
different. realemu implements the opcodes in a generic way without
all these switch(opsize){} cases in order to minimize code size. and
it doesnt dereference pointers in the decode phase, but passes the
opcode handler a Iarg * that will be read or written with ar() or aw()
in the handler.
--
cinap
---BeginMessage---
mkfile is fixed now. will install itself into /$objtype/bin/aux/realemu
and install realemu (8) manpage.
impovement on the manpage is welcome as my english is not so good :)
Again, I'm delaying testing because I need to install a different
video card in the available hardware, but I'm looking forward to doing
that.
I have installed the pertinent bits in preparation, we'll see what
happens.
Thanks for tidying up. On my side what I'm still missing is a
description of #P/realmode and #P/realmodemem; realemu's manpage
suggests that these can be found in arch(3) but my copy of that man
page has nothing to say about it (not your problem, of course).
The realemu(8) man page is pretty adequate now, thank you for that,
too.
Would it make sense, in your opinion, to backport these changes to 8i
and have that added to the distribution as well?
++L
---End Message---
Re: [9fans] realemu update
On Mon, Mar 07, 2011 at 11:39:10AM +0100, cinap_len...@gmx.de wrote: the /dev/realmode intraface was not documented, but it is very simple. Thank you for explaining this. /dev/realmodemem is just an image of the first megabyte of physical memory that is addressable from 16 bit realmode. That being where the machine's BIOS resides, if memory serves. Plus whatever can fit in there if one chooses to use the space. I'll understand things better with the fesh background, thank you. plan9 reserves a 4k page at 0x9000 (defined as RMBUF) that can be refered to in the bios call as data buffer. previously, this was the only offset range that could be written with /dev/realmodemem. I think I get it, but I'll experiment with it to make sure. in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h) (in x86 machine byte order?) containing the register contents and the interrupt number of the bios call you want to make. the write returns when the BIOS call returns and the machine state can be read back from /dev/realmode. That is a neat idea. realemu did a little extension to the interface: it allows reading and writing the whole address space and in case the trap is zero in the Ureg, it will copy ss, sp, cs, and pc in the virtual cpu state too and not make a BIOS interrupt. this is used by loadcom.c to run dos .com files in the emulator. This bit is harder to get my mind around, but I'll explore the source code to make better sense of it. It all sounds very sensible. 8i was never in a working or finished state... That suggests that you see no value in a working 8i implementation, it's tempting to take your word for it :-) All in all, there are only so many brain cycles available. ++L
Re: [9fans] realemu update
On Mon, Mar 07, 2011 at 11:39:10AM +0100, cinap_len...@gmx.de wrote:
/dev/realmodemem is just an image of the first megabyte of
physical memory that is addressable from 16 bit realmode.
That being where the machine's BIOS resides, if memory serves.
Plus whatever can fit in there if one chooses to use the space.
I'll understand things better with the fesh background, thank you.
yes, exactly. it also contains the data setup by the bios.
this is the memory map from realemu main.c, one entry for each
64k block:
static Bus memio[] = {
/* 0 */ memory, rmem, wmem, /* RAM: IVT, BIOS data area */
/* 1 */ memory, rmem, wmem, /* custom */
/* 2 */ nil,rbad, wbad,
/* 3 */ nil,rbad, wbad,
/* 4 */ nil,rbad, wbad,
/* 5 */ nil,rbad, wbad,
/* 6 */ nil,rbad, wbad,
/* 7 */ nil,rbad, wbad,
/* 8 */ nil,rbad, wbad,
/* 9 */ memory, rmem, wmem, /* RAM: extended BIOS data area */
/* A */ memory, rmem, wrealmem, /* RAM: VGA framebuffer */
/* B */ memory, rmem, wrealmem, /* RAM: VGA framebuffer */
/* C */ memory, rmem, wbad, /* ROM: VGA BIOS */
/* D */ nil,rbad, wbad,
/* E */ memory, rmem, wbad, /* ROM: BIOS */
/* F */ memory, rmem, wbad, /* ROM: BIOS */
};
on startup, we read in all the readable memory from the host machine.
this means, that if the host machine is not a x86 with a bios that
mapped the roms for us it will not work. to make this work have to do
the same thing the bios on a pc makes like setting up a realmode
interrupt table and discover and map in the vga roms.
the write returns when the BIOS call returns and the machine
state can be read back from /dev/realmode.
That is a neat idea.
yeah, its the power of filesystem abstraction all over again :)
also, with realemu, you can interrupt the write to /dev/realmode in
case the code hangs in a endless loop. otherwise it will return if
the code comes back from the interrupt call to the bios or when the
code produces some kind of exception. errstr will be set to a string
describing the exception and the exception number will be in u-trap
when reading /dev/realmode back.
--
cinap
Re: [9fans] realemu update
in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h) (in x86 machine byte order?) containing the register contents and the interrupt number of the bios call you want to make. yes. you should use libmach to do this dirty work. - erik
Re: [9fans] realemu update
On Mon, Mar 07, 2011 at 07:23:36AM -0500, erik quanstrom wrote: in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h) (in x86 machine byte order?) containing the register contents and the interrupt number of the bios call you want to make. yes. you should use libmach to do this dirty work. Erik, what have you got in mind? Philosophically, you are perfectly correct, but the implementation would seem like overkill to me. Maybe a libmach function to build the registers from user-mode values, but surely not additional complexities in /dev/realmode to set registers, shall we say, from user-mode text values? ++L
Re: [9fans] realemu update
On Mon, Mar 7, 2011 at 7:23 AM, erik quanstrom quans...@quanstro.net wrote: in /dev/realmode, you write a struct Ureg (from /386/include/ureg.h) (in x86 machine byte order?) containing the register contents and the interrupt number of the bios call you want to make. yes. you should use libmach to do this dirty work. huh? what does libmach (which takes apart executables) have to do with any of this? the interface is well defined and portable: it is an x86 Ureg struct in x86 byte order, because you are executing x86 code. i think cinap's structuring of realemu as a file server is very elegant, and i say that as the author of both 8i and /dev/realmode. it's one of those things that is completely unexpected and yet falls out quite naturally from the general plan 9 approach. very very cool. russ
Re: [9fans] realemu update
On Mon, Mar 07, 2011 at 09:19:58AM -0500, Russ Cox wrote: huh? what does libmach (which takes apart executables) have to do with any of this? Did I get the wrong impression when I perceived libmach, as released with GoLang - cause that's where I looked - seemingly quite capable of synthesising as well as analysing binary images? ++L
Re: [9fans] realemu update
huh? what does libmach (which takes apart executables) have to do with any of this? Did I get the wrong impression when I perceived libmach, as released with GoLang - cause that's where I looked - seemingly quite capable of synthesising as well as analysing binary images? i think you did. libmach has routines to read executables and object files (8.out and *.8) but not to write them. the programs that write them (8a, 8l, 8c, 8g) all use custom code, mainly because they have their own internal representations of the instruction stream, tailored to the kinds of annotations they need. 8l even has its own reader for *.8 files, for much the same reason. russ
Re: [9fans] recent plan9.iso on hosted kvm/qemu
Stanley Lieber wrote: On Sun Mar 6 22:33:33 EST 2011, stanley.lie...@gmail.com wrote: 9atom's 9load prints %d e820 entries on boot. is that number 0? found 7 e8s0 entries Then it freezes. it's not the e820 code, then. it's either falling over initializing the console, or it's falling over probing devices for the .ini file. after e820, 9load starts up the console and probes devices looking for a .ini file. i would think the odds are good that 9load has found an i/o port that should not be touched. devices are probed in this order floppy. ether, cd, sd. i don't really have a kvm setup, but if it's possible, you might try removing devices (espeically ethernet devices) from a copy of 9load until you find something that boots, then add 'em back in till it doesn't. sounds tedious, no? :-) I'm perfectly willing. Two main problems at this point: - I don't have immediate access to amd64 hardware to setup my own KVM/qemu. I learned the hard way that KVM inside another qemu or VMware guest doesn't work. - Changing out the CD-ROM image on the hosted VPS requires sending an e-mail to technical support and waiting up to 24 hours for a response. I've been told allowing users to dynamically change CD-ROM images is not an option. Jack: If you reading this, do you want to try this with your cron-swapped floppy images? -sl I would be willing, definitely. However, I am committed to finishing the setup of a cpu/auth server in the VPS right now (I've got it installed, just need to find time to make the migration from terminal to cpu/auth -- probably lunch break today). I want to reach the milestone of serving a page over http (which is the primary purpose of this VPS in the first place). Once that is done, I can bring it down and start playing around with 9loads and kernels loaded on my floppy image. Also, see about setting up the floppy cron job on your vps. If anything, having a floppy there makes things so much easier to quickly play with a new kernel. No need to master a new install cd and have them waste all that bandwidth. Also, I noticed that the probing plan9.ini step in the loader looks at the floppy first even if booting off the hd. Since I couldn't remove the floppy all together, I have my install's plan9.ini merged into the plan9.ini of the floppy. Just a minor annoyance I had no idea existed :). Although it is a great little feature to rescue the system if I bork my plan9.ini... Also, I really need to thank fgb as he gave me a little tip on irc about his modified 9load that allows you to pass new plan9.ini variables at boot. I got disconnected before I could acknowledge. I haven't tried it yet, but it could be useful. -Jack
Re: [9fans] realemu update
With the latest realemu, graphics and rio are finally working in my VMware Workstation 6.5.1 guest: % aux/vga -m vesa -p vesa flagUlinear|Hlinear vesa sigVESA 2.0 vesa oemV M ware, Inc. VBE support 2.0 2.0 vesa vendor VMware, Inc vesa productVMware virtual machine vesa rev2.0 vesa cap 8-bit-dac not-vga vesa mem134217728 vesa mode 0x100 640x400x8 m8 packed vesa mode 0x101 640x480x8 m8 packed vesa mode 0x103 800x600x8 m8 packed vesa mode 0x105 1024x768x8 m8 packed vesa mode 0x107 1280x1024x8 m8 packed vesa mode 0x10e 320x200x16 r5g6b5 direct vesa mode 0x111 640x480x16 r5g6b5 direct vesa mode 0x114 800x600x16 r5g6b5 direct vesa mode 0x117 1024x768x16 r5g6b5 direct vesa mode 0x11a 1280x1024x16 r5g6b5 direct vesa mode 0x120 320x200x8 m8 packed vesa mode 0x121 320x400x8 m8 packed vesa mode 0x122 640x400x8 m8 packed vesa mode 0x123 640x480x8 m8 packed vesa mode 0x124 800x600x8 m8 packed vesa mode 0x125 1024x768x8 m8 packed vesa mode 0x126 1152x864x8 m8 packed vesa mode 0x127 1280x960x8 m8 packed vesa mode 0x128 1280x1024x8 m8 packed vesa mode 0x129 1400x1050x8 m8 packed vesa mode 0x12a 1600x1200x8 m8 packed vesa mode 0x12b 1792x1344x8 m8 packed vesa mode 0x12c 1856x1392x8 m8 packed vesa mode 0x12d 1920x1440x8 m8 packed vesa mode 0x12e 320x200x16 r5g6b5 direct vesa mode 0x12f 320x400x16 r5g6b5 direct vesa mode 0x130 640x400x16 r5g6b5 direct vesa mode 0x131 640x480x16 r5g6b5 direct vesa mode 0x132 800x600x16 r5g6b5 direct vesa mode 0x133 1024x768x16 r5g6b5 direct vesa mode 0x134 1152x864x16 r5g6b5 direct vesa mode 0x135 1280x960x16 r5g6b5 direct vesa mode 0x136 1280x1024x16 r5g6b5 direct vesa mode 0x137 1400x1050x16 r5g6b5 direct vesa mode 0x138 1600x1200x16 r5g6b5 direct vesa mode 0x139 1792x1344x16 r5g6b5 direct vesa mode 0x13a 1856x1392x16 r5g6b5 direct vesa mode 0x13b 1920x1440x16 r5g6b5 direct vesa mode 0x13c 320x200x32 x8r8g8b8 direct vesa mode 0x13d 320x400x32 x8r8g8b8 direct vesa mode 0x13e 640x400x32 x8r8g8b8 direct vesa mode 0x13f 640x480x32 x8r8g8b8 direct vesa mode 0x140 800x600x32 x8r8g8b8 direct vesa mode 0x141 1024x768x32 x8r8g8b8 direct vesa mode 0x142 1152x864x32 x8r8g8b8 direct vesa mode 0x143 1280x960x32 x8r8g8b8 direct vesa mode 0x144 1280x1024x32 x8r8g8b8 direct vesa mode 0x145 1400x1050x32 x8r8g8b8 direct vesa mode 0x146 1600x1200x32 x8r8g8b8 direct vesa mode 0x147 1792x1344x32 x8r8g8b8 direct vesa mode 0x148 1856x1392x32 x8r8g8b8 direct vesa mode 0x149 1920x1440x32 x8r8g8b8 direct vesa mode 0x14a 1366x768x8 m8 packed vesa mode 0x14b 1366x768x16 r5g6b5 direct vesa mode 0x14c 1366x768x32 x8r8g8b8 direct vesa mode 0x14d 1680x1050x8 m8 packed vesa mode 0x14e 1680x1050x16 r5g6b5 direct vesa mode 0x14f 1680x1050x32 x8r8g8b8 direct vesa mode 0x150 1920x1200x8 m8 packed vesa mode 0x151 1920x1200x16 r5g6b5 direct vesa mode 0x152 1920x1200x32 x8r8g8b8 direct vesa mode 0x153 2048x1536x8 m8 packed vesa mode 0x154 2048x1536x16 r5g6b5 direct vesa mode 0x155 2048x1536x32 x8r8g8b8 direct vesa mode 0x156 320x240x8 m8 packed vesa mode 0x157 320x240x16 r5g6b5 direct vesa mode 0x158 320x240x32 x8r8g8b8 direct vesa mode 0x159 400x300x8 m8 packed vesa mode 0x15a 400x300x16 r5g6b5 direct vesa mode 0x15b 400x300x32 x8r8g8b8 direct vesa mode 0x15c 512x384x8 m8 packed vesa mode 0x15d 512x384x16 r5g6b5 direct vesa mode 0x15e 512x384x32 x8r8g8b8 direct vesa mode 0x15f 854x480x8 m8 packed vesa mode 0x160 854x480x16 r5g6b5 direct vesa mode 0x161 854x480x32 x8r8g8b8 direct vesa mode 0x162 1280x720x8 m8 packed vesa mode 0x163 1280x720x16 r5g6b5 direct vesa mode 0x164 1280x720x32 x8r8g8b8 direct vesa mode 0x165 1920x1080x8 m8 packed vesa mode 0x166 1920x1080x16 r5g6b5 direct vesa mode 0x167 1920x1080x32 x8r8g8b8 direct vesa mode 0x168 1280x800x8 m8 packed vesa mode 0x169 1280x800x16 r5g6b5 direct vesa mode 0x16a 1280x800x32 x8r8g8b8 direct vesa mode 0x16b 1440x900x8 m8 packed vesa mode 0x16c 1440x900x16 r5g6b5 direct vesa mode 0x16d 1440x900x32 x8r8g8b8 direct vesa mode 0x16e 720x480x8 m8 packed vesa mode 0x16f 720x480x16 r5g6b5 direct vesa mode
Re: [9fans] recent plan9.iso on hosted kvm/qemu
Also, I really need to thank fgb as he gave me a little tip on irc about his modified 9load that allows you to pass new plan9.ini variables at boot. I got disconnected before I could acknowledge. I haven't tried it yet, but it could be useful. not quite sure what you mean by this, but 9load-e820 allows a var=val at any prompt. - erik
Re: [9fans] realemu update
Cinap suggested invoking realemu in a subshell so that the
process exits after aux/vga completes. The following is a patch
for the man page.
-sl
% diff -n -c /sys/man/8/realemu.orig /sys/man/8/realemu
/sys/man/8/realemu.orig:84,89 - /sys/man/8/realemu:84,102
the
.I srvname
argument then it is ignored, otherwise it will used.
+ .SH EXAMPLES
+ The
+ .I realemu
+ process is only needed when accessing
+ .B /dev/realmode.
+ To invoke a subshell so that
+ .I realemu
+ exits normally after
+ .B aux/vga
+ completes:
+ .IP
+ .EX
+ % @{rfork n; aux/realemu; aux/vga -m vesa -l $vgasize}
.SH SOURCE
.B /sys/src/cmd/aux/realemu
.SH SEE ALSO
Re: [9fans] recent plan9.iso on hosted kvm/qemu
Also, I really need to thank fgb as he gave me a little tip on irc about his modified 9load that allows you to pass new plan9.ini variables at boot. I got disconnected before I could acknowledge. I haven't tried it yet, but it could be useful. not quite sure what you mean by this, but 9load-e820 allows a var=val at any prompt. This is standard on 9atom.iso? I can't access my VPS from here at work but I'll give it a try tonight. -sl
Re: [9fans] recent plan9.iso on hosted kvm/qemu
On Mon Mar 7 12:06:34 EST 2011, stanley.lie...@gmail.com wrote: Also, I really need to thank fgb as he gave me a little tip on irc about his modified 9load that allows you to pass new plan9.ini variables at boot. I got disconnected before I could acknowledge. I haven't tried it yet, but it could be useful. not quite sure what you mean by this, but 9load-e820 allows a var=val at any prompt. This is standard on 9atom.iso? I can't access my VPS from here at work but I'll give it a try tonight. yup. - erik
[9fans] off list - Re: recent plan9.iso on hosted kvm/qemu
On Mon, Mar 7, 2011 at 12:06 PM, Jack Norton j...@0x6a.com wrote: erik quanstrom wrote: On Sun Mar 6 22:33:33 EST 2011, stanley.lie...@gmail.com wrote: 9atom's 9load prints %d e820 entries on boot. is that number 0? found 7 e8s0 entries Then it freezes. it's not the e820 code, then. it's either falling over initializing the console, or it's falling over probing devices for the .ini file. after e820, 9load starts up the console and probes devices looking for a .ini file. i would think the odds are good that 9load has found an i/o port that should not be touched. devices are probed in this order floppy. ether, cd, sd. i don't really have a kvm setup, but if it's possible, you might try removing devices (espeically ethernet devices) from a copy of 9load until you find something that boots, then add 'em back in till it doesn't. sounds tedious, no? :-) - erik Well I've got some other observations of interest. As I mentioned, I installed with *noe820scan=1 successfully. I was in the middle of configuring and playing around when I realized I had no ethernet car. bind -a '#l' /dev returned 'no free devices'. The vps has an e1000 card (PRO/1000) plugged into it, so I naively put ether0=type=igbe in plan9.ini. Now it hangs right where 9load would normally say no ethernet devices found or something similar. How odd. -Jack Sorry if this is a duplicate, but I'm not sure my earlier private e-mail to you went through. Do you happen to know who the support staff member is that setup your cron job? The people in #arpnetworks are not being helpful, and Garry seems unaware of what you've setup. I'd like to run through some tests myself but I haven't been able to scrounge up amd64 hardware to setup my own Ubuntu Jaunty server. Thanks, -sl
Re: [9fans] off list - Re: recent plan9.iso on hosted kvm/qemu
Stanley Lieber wrote: On Mon, Mar 7, 2011 at 12:06 PM, Jack Norton j...@0x6a.com wrote: erik quanstrom wrote: On Sun Mar 6 22:33:33 EST 2011, stanley.lie...@gmail.com wrote: 9atom's 9load prints %d e820 entries on boot. is that number 0? found 7 e8s0 entries Then it freezes. it's not the e820 code, then. it's either falling over initializing the console, or it's falling over probing devices for the .ini file. after e820, 9load starts up the console and probes devices looking for a .ini file. i would think the odds are good that 9load has found an i/o port that should not be touched. devices are probed in this order floppy. ether, cd, sd. i don't really have a kvm setup, but if it's possible, you might try removing devices (espeically ethernet devices) from a copy of 9load until you find something that boots, then add 'em back in till it doesn't. sounds tedious, no? :-) - erik Well I've got some other observations of interest. As I mentioned, I installed with *noe820scan=1 successfully. I was in the middle of configuring and playing around when I realized I had no ethernet car. bind -a '#l' /dev returned 'no free devices'. The vps has an e1000 card (PRO/1000) plugged into it, so I naively put ether0=type=igbe in plan9.ini. Now it hangs right where 9load would normally say no ethernet devices found or something similar. How odd. -Jack Sorry if this is a duplicate, but I'm not sure my earlier private e-mail to you went through. Do you happen to know who the support staff member is that setup your cron job? The people in #arpnetworks are not being helpful, and Garry seems unaware of what you've setup. I'd like to run through some tests myself but I haven't been able to scrounge up amd64 hardware to setup my own Ubuntu Jaunty server. Thanks, -sl No problem. I am in contact with Garry Dolley at Arp networks. I don't have his actual email as it is masked by their support mailer. From what I can tell, he is only active late in the day and in the evening (I'm on central time in the US btw). He seems eager to help and doesn't mind that I send him numerous emails all day long... The latest on my side is I've asked for a rtl8139 card instead of the e1000 (this is mainly motivated by my own qemu setup, which uses the rtl8139 and works lovely). I'm also not interested in setting up their exact kvm setup (partly because I don't want to deal with this libvirt business -- looks like a hellish nightmare). In the mean time I am loading a floppy today with 9load from eric and 9atom kernel. I won't have time to recompile or play with 9load until later this evening (if that) so I don't think I'll have much else to report until tomorrow. -Jack
Re: [9fans] recent plan9.iso on hosted kvm/qemu
years ago I needed to set some variables at boot time so I could get Plan 9 running. http://9fans.net/archive/2005/12/70 On Mon, Mar 7, 2011 at 1:24 PM, erik quanstrom quans...@labs.coraid.com wrote: Also, I really need to thank fgb as he gave me a little tip on irc about his modified 9load that allows you to pass new plan9.ini variables at boot. I got disconnected before I could acknowledge. I haven't tried it yet, but it could be useful. not quite sure what you mean by this, but 9load-e820 allows a var=val at any prompt. - erik -- Federico G. Benavento
[9fans] Listing a directory
Hi, In 9P, if I wish to list a directory, I need to TWalk to the directory, TOpen the directory fid from the walk, and then TRead till I have all of the contents of the directory. If the directory's contents do not fit in a single read, I imagine I need to loop around TOpen / Tread / / Tread / TOpen, till I get the whole contents and see the same QIDs in each open, to get a coherent listing. (is this accurate?) Unfortunately, a TOpened FID to a directory cannot be used for walking it (why?); so the only use of a TOpened fid to a directory is to list it or to get a QID. Would it be reasonable for a TOpened fid to a directory to create a copy of the directory listing at the time of the RPC? -- vs
Re: [9fans] Listing a directory
On Mon, Mar 7, 2011 at 7:09 PM, Venkatesh Srinivas m...@acm.jhu.edu wrote: In 9P, if I wish to list a directory, I need to TWalk to the directory, TOpen the directory fid from the walk, and then TRead till I have all of the contents of the directory. If the directory's contents do not fit in a single read, I imagine I need to loop around TOpen / Tread / / Tread / TOpen, till I get the whole contents and see the same QIDs in each open, to get a coherent listing. (is this accurate?) Offsets track where you are in the metadata, servers have multiple approaches to dealing with this, usually there is some form of cookie in the fid which tracks the last offset red and maybe a cache of where it was in the directory listing. I think the QID matching and coalescing is more of a union bind mechanism and happens if I am not mistaken by a higher level entity (like ls) Unfortunately, a TOpened FID to a directory cannot be used for walking it (why?); so the only use of a TOpened fid to a directory is to list it or to get a QID. Would it be reasonable for a TOpened fid to a directory to create a copy of the directory listing at the time of the RPC? That may be a potential back-end implementation on the server, I believe it to be the only way to avoid the sort of race conditions you might expect otherwise. But I haven't implemented the server side of that code, only the client which is tricky, but easier -- so I'm sure someone else may have a better opinion. -eric
[9fans] troff pic bug report - acid debug - no fix yet
Hi all
Here is a bug report for troffs pic preprocessor.
It crashes when the commands is in a square bracket and you loose
track of the labels
--- test file contents
pseudo@helios; cat test.p
.PS
define missing { [
O: box invis wid 2.5 ht 1;
circle diam 0.1 with .e at P1;
] }
missing with .c at 0,0
.PE
--- crash report and acid
pseudo@helios; cat test.p | pic
.lf 1 -
pic: no such place as P1 near -:8
context is
circle diam 0.1 with .e at P1; with .c at 0,0
pic 44699: suicide: sys: trap: fault read addr=0x10 pc=0x89b9
pseudo@helios; acid 44699
/proc/44699/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: src(0x89b9)
/sys/src/cmd/pic/circgen.c:49
44 case WITH:
45 with = ap-a_val.i;
46 break;
47 case AT:
48 ppos = ap-a_val.o;
49 curx = ppos-o_x;
50 cury = ppos-o_y;
51 at++;
52 break;
53 case INVIS:
54 battr |= INVIS;
acid:
Re: [9fans] recent plan9.iso on hosted kvm/qemu
I'm installed. Made a custom boot floppy with the plan9.ini from plan9.iso's boot.img. In addition, one of either *noe820scan=1 or *norealmode=1 were required to avoid the freeze-up mentioned throughout this thread. The floppy's boot menu points to kernels on the plan9.iso that is configured as the IDE secondary master. Taking another cue from Jack's experiences, I asked for the NIC to be configured as a RTL8139. With either option (*noe820scan or *norealmode), my installed system can't pass icmp or tcp traffic to hosts on the local network. Networking is configured as normal (in fact, the configuration is identical to the Plan9 in qemu I had working on this same hardware under KVM/qemu - OpenBSD - kqemu/qemu - Plan 9). After booting, the contents of /net/iproute, ip/ndb, etc., seem correct and are consistent with my other, working, Plan 9 systems. The new system can ping it's own IP address, but cannot be pinged from the local network. I suspect there may be some sort of arp confusion in the ethernet switch. This system was previously configured with the same IP address, bridged from kqemu/qemu to the kqemu/qemu host's external interface (which itself was a virtual interface hosted on KVM/qemu). With this new configuration, the MAC address has changed. I've submitted a support request to check it out. -sl
Re: [9fans] realemu update
applied, thank you. also fixed some bugs in code:
properly convert the register values from the 386 ureg.
read back #P/realmodemem on every access as some graphics cards
use the a segment as memory mapped i/o. (Matrox MILLENNIUM)
we dont use #v/vgabios anymore and rely on #P/realmodemem to
have the latest patches applied.
fix instruction formating bug.
always truncate physical memory addresses to 20bit.
--
cinap
---BeginMessage---
Cinap suggested invoking realemu in a subshell so that the
process exits after aux/vga completes. The following is a patch
for the man page.
-sl
% diff -n -c /sys/man/8/realemu.orig /sys/man/8/realemu
/sys/man/8/realemu.orig:84,89 - /sys/man/8/realemu:84,102
the
.I srvname
argument then it is ignored, otherwise it will used.
+ .SH EXAMPLES
+ The
+ .I realemu
+ process is only needed when accessing
+ .B /dev/realmode.
+ To invoke a subshell so that
+ .I realemu
+ exits normally after
+ .B aux/vga
+ completes:
+ .IP
+ .EX
+ % @{rfork n; aux/realemu; aux/vga -m vesa -l $vgasize}
.SH SOURCE
.B /sys/src/cmd/aux/realemu
.SH SEE ALSO
---End Message---
