From: Jeff D. <jd...@ka...> - 2000-01-12 15:49:35
|
> Jeff, am I allowed to advertise my project here? Sure. It's related, and you've got a pointer to my stuff on your site :-) > Please note that Cygwin can't implement mmap(MAP_FIXED) for Windows 95/ > 98. That's probably a Very Bad Thing if you want to run an operating > system in user mode. That would hurt. You definitely want to be able to map pages and have them go where you want. Posix compatibility is definitely not enough. I think the biggest problem would be the ability to intercept and modify Linux system calls. Nothing works without that. There is also code that is written with knowledge about how the system call path works. I'm going to get rid of that, but for now, it's a definite portability problem. Jeff |
From: Glenn C. <GCh...@pr...> - 2000-01-12 15:52:29
|
> Posix compatibility is definitely not enough. I think the > biggest problem would be the ability to intercept and modify > Linux system calls. Nothing works without that. Ah, a light dawns. I wondered (without wondering enough to learn the Linux and uml internals) how you virtualized the machine. This combines with the comments about debugging yourself to explain the fundamentals... Cool. |
From: lars b. <la...@no...> - 2000-01-12 16:07:05
|
Glenn Chambers <GCh...@pr...> writes: > > Posix compatibility is definitely not enough. I think the > > biggest problem would be the ability to intercept and modify > > Linux system calls. Nothing works without that. > Ah, a light dawns. I wondered (without wondering enough to > learn the Linux and uml internals) how you virtualized the > machine. This combines with the comments about debugging > yourself to explain the fundamentals... I wonder if a uml-light would be possible by just redirecting the shared library system call functions? |
From: Jeff D. <jd...@ka...> - 2000-01-12 18:33:05
|
> > Posix compatibility is definitely not enough. I think the > > biggest problem would be the ability to intercept and modify > > Linux system calls. Nothing works without that. > > Ah, a light dawns. I wondered (without wondering enough to learn the > Linux and uml internals) how you virtualized the machine. This > combines with the comments about debugging yourself to explain the > fundamentals... Actually, with an OS that maps reasonably well to Linux, it might not be hard to replace the top layer (the bit that intercepts system calls) with its equivalent. It would run its own binaries and map those syscalls onto Linux syscalls. Everything below that layer it Posix, I think. Except maybe some of the mmaping that I do. Jeff |
From: Cedric A. <ced...@in...> - 2000-01-13 01:03:40
|
Jeff Dike writes: > > > Posix compatibility is definitely not enough. I think the > > > biggest problem would be the ability to intercept and modify > > > Linux system calls. Nothing works without that. > > > > Ah, a light dawns. I wondered (without wondering enough to learn the > > Linux and uml internals) how you virtualized the machine. This > > combines with the comments about debugging yourself to explain the > > fundamentals... > > Actually, with an OS that maps reasonably well to Linux, it might > not be hard > to replace the top layer (the bit that intercepts system calls) with its > equivalent. It would run its own binaries and map those syscalls > onto Linux > syscalls. > > Everything below that layer it Posix, I think. Except maybe some of the > mmaping that I do. Actually, I wondered too if uml could be ported to Windows NT, but after just running strace on uml-linux, I still don't understand perfectly how it works :-) Did you post some information about it somewhere (kernel list, newsgroup) ? Ok, a quick look at /proc/*/maps, shows that maybe you allocated a file for the physical memory and mmaped it at the right places in each thread (this is how I suggested to make a user-space freemware, using also a main process that ptraces another to catch exceptions, software interrupts, emulate specific instructions... and setting the proper memory map at each context switch). Anyway for NT, the question would rather be whether how much you need out of ANSI-C ? All what I know is the following: - NT (Windows?) has the equivalent of "ptrace" except that you only get the DLL load/unload and the exceptions (with the "debugging functions"). - NT debugging process receives an exception_event when you execute an "int 0x80". I made a test program: parent+child, where the child would execute an int 0x80, the parent would see this, get the eip address, change the "int 0x80" to "nop ; nop", and have the child going on. This works. - My Windows 98 locks instantly _sometimes_ when running the same program executing "int 0x80". Otherwise the system display a full screen fatal error, ask for enter to be pressed and stop the process normally. According to "Undocumented Windows NT", Set_PM_Int_Vector could be used to hook a software interrupt, though. - NT has some file maping and some virtual memory management functions that should provide some of the capabilities of mmap (and more). The nice thing about NT, is that it has some way to manipulate the file/memory maping of other processes, so maybe it would do. For 95, there are additionnal limitations (such as copy-on-write forced when maping files for write), that were probably the source of problems for mmap in Cygnus tools. -- Cedric |
From: Jeff D. <jd...@ka...> - 2000-01-12 18:26:16
|
la...@no... said: > I wonder if a uml-light would be possible by just redirecting the > shared library system call functions? vfork has to run on a different stack, although you could just make vfork a synonym for fork in the shared library. You'd also have to find a way to locate kernel addresses (or maybe just a single kernel address) from the shared library. That also doesn't help static executables. > Great, but I'll be damned if I can find it. :) There's a way to get my page hit counts up. Just tell people that there's a link to their site somewhere on mine :-) Jeff |
From: Jeff D. <jd...@ka...> - 2000-01-13 02:34:11
|
ced...@in... said: > Actually, I wondered too if uml could be ported to Windows NT, but > after just running strace on uml-linux, I still don't understand > perfectly how it works :-) Really? I don't know what more information you could ask for :-) Actually, you only straced the input thread, which probably the least interesting thread in the whole thing. It just sits in a select waiting for input on file descriptors that the other threads think are interesting and sending it to them > Did you post some information about it somewhere (kernel list, > newsgroup) ? I had some lame information on my old web site, but it got out of date pretty quickly. I'm much better at writing code than writing down explanations of it (or at least much more interested) :-( And if any of the slackers out there are interested in doing something useful, and can write this stuff up by reading sketchy explanations from me and the code, I'd be happy to put the results up on the web site... > Ok, a quick look at /proc/*/maps, shows that maybe you allocated a > file for the physical memory and mmaped it at the right places in each > thread (this is how I suggested to make a user-space freemware, using > also a main process that ptraces another to catch exceptions, software > interrupts, emulate specific instructions... and setting the proper > memory map at each context switch). Right, except that big chunk at 0x50000000 also includes the kernel virtual memory. The "physical" memory gets mmaped appropriately into the kernel vm area and into process vm areas. > - NT debugging process receives an exception_event when you execute > an "int 0x80". I made a test program: parent+child, where the child > would execute an int 0x80, the parent would see this, get the eip > address, change the "int 0x80" to "nop ; nop", and have the child > going on. This works. Are you sure that the int 0x80 didn't execute? You nulled it out, but it kind of seems to me that you nulled it out after the fact. > - My Windows 98 locks instantly _sometimes_ when running the same > program executing "int 0x80". According to Lars, Win98 is a lost cause because of lack of mmap (or at least lack of it in the cygwin libraries). From what you've said, it looks like NT has everything needed. Go for it :-) Jeff |
From: lars b. <la...@no...> - 2000-01-12 16:04:39
|
Jeff Dike <jd...@ka...> writes: > > Jeff, am I allowed to advertise my project here? > Sure. It's related, and you've got a pointer to my stuff on your site :-) Great, but I'll be damned if I can find it. :) I'll just point out that I'm doing this user-mode port with a slightly different angle. It's might be duplicated effort, but hey, this is for fun. My Linux/a386 project is just like uml, but with a separate CPU/hardware layer called a386. I think this will make it easier to port to other Unices, as well as make it easier to port other operating systems to user-mode. NetBSD/a386 is my next target when Linux/a386 stabilizes. See http://a386.nocrew.org/ and http://linux.a386.nocrew.org/ (new locations; Jeff, please update) > Posix compatibility is definitely not enough. I think the biggest problem > would be the ability to intercept and modify Linux system calls. I don't think ptrace() is in POSIX at all, so that is a huge problem. |