From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7b7b420200424ead0c949d6b3cf8ff9d@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Linuxemu From: "Russ Cox" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 28 Nov 2002 11:33:10 -0500 Topicbox-Message-UUID: 29f3b78e-eacb-11e9-9e20-41e7f4b1d025 > thanks a lot for linuxemu! However, I was only able to run the stuff > included with /bin. Other linux progs (sort, bc...) did not work > (see below). May it be they were dynamically linked with glibc? > Thus, isn't there a dosemu around there? (Perhaps it would be easier right, /bin is typically statically linked, while /usr/bin is dynamically linked. like i said, it wouldn't be too hard to make dynamic linking work. in theory, linuxemu ld-linux.so.1 bin/a.dynamic is supposed to work, but unfortunately ld-linux.so.1 wants to be loaded where the linuxemu text segment is. you'd need to move the linuxemu text segment somewhere else and then segdetach it before calling elfload. it's entirely doable, especially since x86 code is position independent. dosemu is much harder because you have to deal with all the weird 16-bit processor modes. at that point it's easier just to simulate the 16-bit processor than to get plan 9 to set up the processor the way you want it. the other problem with dosemu is that the set of system calls doesn't map as nicely to plan 9 system calls. i wrote one of those too, but only enough to execute the vga bios code. the theory was that this might be significantly easier than the kernel support required. i still think that's true, but it didn't just work. there are some things that need certain timing to work out properly, and the simulator is too slow. at least, that's my theory. i think there's still hope for it -- you could hard code certain sequences that had to run nearer to full speed and run them as one pseudo-op in the simulator.