From: Jeff D. <jd...@ka...> - 2002-05-03 04:12:28
Attachments:
uml.win32.diff
|
ch...@to... said: > Broadly I can think of two approaches. > 1. Build uml-linux binary for target windows (maybe using cygwin?) > To load all other binaries we could use LINE approach. Not sure if > this would work, since my attempt to build kernel on windows/cygwin was > disheartening to say the least! (I am not even sure if this approach > makes sense. I am giving up on this approach for now) This is the way to go. Attached is a patch from Dan Aloni which makes UML compile on Windows, but not too much else. It should get you started. > 2. More promising approach is to load the uml-linux kernel binary > under > LINE and load all other binaries under this environment. This seems > promising and hence I am continuing with this approach for now. This not the way to go. LINE has a role in UML, but it is not to provide a Linux emulation environment for UML to run in. LINE is the Windows equivalent of the UML tracing thread, which intercepts the system calls of its processes and makes them run inside UML. > Next was the temporary memory mapped files. Cygwin doesnt like > unlinking files with open handles. This needs fixing. Just don't unlink them for now. > Next I faced problems doing the remap_data() of the text and data > segment. As far as I can gather this code is mmapping another segment, > copying data, and then it unmaps the original segment and remaps it. > It then unmaps the new segment. The kernel kept crashing after the > unmaps. Could someone please tell me what the purpose of thi > switcheroo is ? The point of switcheroo is to make the UML text and data shared between all its processes when they live in separate address spaces. Without this, if a process changed a piece of kernel data, that page would be COWed to that process and the change wouldn't be visible to any other process. This would break things very badly. So, the UML text and data segments are copied into anonymous memory, which is then mapped MAP_SHARED in their place. This makes UML text and data shared among all the processes. You can turn this off for now, but if you don't find a way to make it work, you'll have to do some extra work in the context switching code at some point. Jeff |
From: David H. <dho...@re...> - 2002-05-03 13:48:36
|
> > > Next was the temporary memory mapped files. Cygwin doesnt like > > > unlinking files with open handles. This needs fixing. > > > > Just don't unlink them for now. > > The Windows "kernel" will not let you delete an open file. (This > DOS feature was ported to NT as well.) It will let you rename an > open file. You can delete an open file, provided it was opened with SHARE_DELETE (I think that's the constant). However, I don't believe that you can reuse the old name after it has been either deleted or renamed until it's closed (since the NT kernel uses the fully qualified name to keep track of objects in memory). One good thing though... Win2K and WinNT both permit hard linking. David |
From: Roger B. <ro...@ro...> - 2002-05-03 16:26:03
|
> You can delete an open file, provided it was opened with SHARE_DELETE (I think > that's the constant). However, I don't believe that you can reuse the old name > after it has been either deleted or renamed until it's closed (since the NT > kernel uses the fully qualified name to keep track of objects in memory). Is the UML port to Win32 going to work on Win95/98/Me as well as the NT family? Roger |
From: Chandan K. <ch...@to...> - 2002-05-03 16:50:59
|
I am not very sure of all the variations, but cygwin provides a pretty standard interface across all the platforms. Not sure if things like VirtualAlloc() etc exist/works fine on Win95/98, but for now I am concentrating on NT/XP. In the long run it will be nice to have UML running on WinXYZ, but for now .. small steps. Chandan > Is the UML port to Win32 going to work on Win95/98/Me as well as the NT > family? > > Roger > > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel > |
From: Jeff D. <jd...@ka...> - 2002-05-03 17:17:22
|
ch...@to... said: > I see. Hmm .. how about loading UML directly into SHARED pages in the > first place? You can't. There's no execve_no_cow syscall. Jeff |
From: Jeff D. <jd...@ka...> - 2002-05-03 17:24:12
|
ro...@ro... said: > Is the UML port to Win32 going to work on Win95/98/Me as well as the > NT family? When Dan was initially doing the UML/Win port a year or so ago, he reported that intercepting int 80 system calls fairly reliably hung Win98. So, I would think that Win95/98 would be doubtful unless Chandan discovers that this can be done without wedging the box. Jeff |
From: Pat V. <pa...@mo...> - 2002-05-07 10:38:00
|
Has anyone considered skipping the Win9X/Me stream altogether and going directly to the NT series OS? The reason I ask is that it would be more efficient to bypass the win32 DLLs and go directly to the kernel itself. I have been lurking for a while, and I've been interested in this specifically for application in my Linux for Windows distribution. Many of my users would be perfectly happy with UML instead of native linux. Pat |
From: Jeff D. <jd...@ka...> - 2002-05-03 17:26:42
|
ch...@to... said: > I would be happy even if we reach the init to begin with ;) Yeah, if you can get init started, that would be a major step forward. Jeff |
From: Chandan K. <ch...@to...> - 2002-05-06 15:16:40
|
Jeff, > > I would be happy even if we reach the init to begin with ;) > > Yeah, if you can get init started, that would be a major step forward. I had quite a success towards this over the weekend. I managed to compile UML on winXP/cygwin with the patch you sent me and I pulled in the changes from the umpl-patch-2.4.18-20 against this. So now I have the latest (oh well, almost latest) UML patched with win32. I will try to keep it up-to-date with new UML changes. After fiddling around with the link options I even managed to get the linux.exe running under Win32 ! Infact it comes up pretty coolly until it tries to do a context switch when it spawns the init process and then it crashes :) Next to do is to port the UML architecture dependencies. Looking at your WVU slides I can see four basic items to be done: - mapping the kernel context shared between all processes. - ptrace - registers, offsets etc - sigcontext - signal frame format All four are currently stubbed out. ptrace interface will be probably the hardest. Win32-cygwin environment lacks the clone() system call and the ptrace library. Win32API does have a DebugActiveProcess() system call which I have been trying to use. It works on a process created by CreateProcess() or a fork system call, and there are problems in sharing the kernel context. Infact the whole capture_signal_stack() etc is currently stubbed out. Anyway, I have just started to find my way around the kernel and it should be quite exciting from here on :) But I would like to co-ordinate with others working on UML/win32 so that there is no duplication in effort. Is there any other documentation (other than the code and the slides) that I can look at? How does the 'current' pointer work? It doesnt seem to be getting initialised right now, and I added in a line of code to initialise it from the init_task, but I not sure if thats the correct thing to do. -Chandan On Fri, 3 May 2002, Jeff Dike wrote: > > Jeff > |
From: Jeff D. <jd...@ka...> - 2002-05-06 17:04:12
|
ch...@to... said: > Infact it comes up pretty coolly until it tries to do a context switch > when it spawns the init process and then it crashes :) Is it really at the first context switch or is it at the first call to kernel_thread()? > It works on a process created by CreateProcess() or a fork system > call, and there are problems in sharing the kernel context. The switcheroo business? You can avoid that by making everything threads running in the same address space. This will also avoid problems with CLONE_FILE. > Infact the whole capture_signal_stack() etc is currently stubbed out. You'll need to deal with that when the first exec (of init) tries to return to userspace. > But I would like to co-ordinate with others working on UML/win32 so > that there is no duplication in effort. Anyone else trying this should speak up, but afaik, no one else is. > Is there any other documentation (other than the code and the slides) > that I can look at? Not really. Ask questions here and I will answer them :-) > How does the 'current' pointer work? The current task structure is located at the bottom of the kernel stack. So, you get its address by clearing the low 14 bits of any address on the stack. And it's not a pointer, so there's not really anything to initialize. Also, send in a boot log whenever you've made some noticable progress :-) Jeff |
From: Chandan K. <ch...@to...> - 2002-05-07 05:29:44
|
> > Infact it comes up pretty coolly until it tries to do a context switch > > when it spawns the init process and then it crashes :) > > Is it really at the first context switch or is it at the first call to > kernel_thread()? It did crash in kernel_thread() (inside do_fork() actually, when it tried to access current->user). I then put in the kludge for current and it went all the to the cpu_idle() and crashed in schedule(). But that doesnt count! I now understand the 'current' business and know whnat needs to be done on windows. The complication is that win32 CreateThread() doesnt take the stack pointer as an argument .. arghh. But it seems like I can set the stack of a thread by SetThreadContext) even though it seems to expect enormous stack size (4 times the uml default) if I want to use things like printf()! > The switcheroo business? You can avoid that by making everything threads > running in the same address space. This will also avoid problems with > CLONE_FILE. The reason why I avoided making threads is because I wanted to use the windows debug API instead of ptrace(). Looks like that is only trouble, and I will stick with threads and thread-debugging APIs which are more restrictive. > > How does the 'current' pointer work? > > The current task structure is located at the bottom of the kernel stack. > So, you get its address by clearing the low 14 bits of any address on the > stack. > > And it's not a pointer, so there's not really anything to initialize. Thanks! Its clear now... cool stuff :) > > Also, send in a boot log whenever you've made some noticable progress :-) > Here is the boot log for a decent run: (Its a WinXP with cygwin environment) This one crashed in do_fork(). If I had a decent text-mode gdb I would have included the stack trace too... ============== boot log ==================== chandan@ONE-XP /usr/src/uml/linux $ ./linux.exe CKERNEL debug 1 CKERNEL debug 2 CKERNEL debug 3 CKERNEL debug 4 CKERNEL debug 5 CKERNEL debug 6 err 0 CKERNEL debug 7 CKERNEL debug 8 CKERNEL debug 9 CALLING SIGNALS: sp @ 0x543000 init_task.task @ 0x541000 win32_clone() creating thread win32_clone() sleeping (child pid 0x750 ... Suspending myself pid @ 0xf6ffb0 pid 0xfffffffe ... win32_clone() setting stack sp @ 0x543000 stack_size 32784 Get context for child 0x750: ESP 0xf6ff54 succ 1 Setting context for child 0x750: ESP 0x54abf0 SetThreadContext returned 1 Resuming myself pid @ 0xf6ffb0 pid 0xfffffffe ... signal_tramp() calling proc @ 0x506fe0 ==== ckcurrent @ 0x548000 ==== lock_kernel.3080: current @ 0x548000 lock_depth 1 Linux version 2.4.18-20um (chandan@ONE-XP) (gcc version 2.95.3-5 (cygwin specia )) #88 SMP Mon May 6 23:54:54 2002 On node 0 totalpages: 8192 zone(0): 0 pages. zone(1): 8192 pages. zone(2): 0 pages. Kernel command line: root=/dev/ubd0 Calibrating delay loop... 0.42 BogoMIPS Memory: 32244k available Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) /proc/cpuinfo not available - skipping CPU capability checks check_sigio() Unimplemented POSIX conformance testing by UNIFIX All CPUs are go! Waiting on wait_init_idle (map = 0x0) All processors have done init_idle chandan@ONE-XP /usr/src/uml/linux $ |
From: Jeff D. <jd...@ka...> - 2002-05-07 11:59:20
|
ch...@to... said: > The complication is that win32 CreateThread() doesnt take the stack > pointer as an argument .. arghh. You absolutely need to be able to specify the stack. How can a create stack interface not take a stack argument anyway? Does it find some free address space by itself for the stack? > But it seems like I can set the stack of a thread by SetThreadContext) > even though it seems to expect enormous stack size (4 times the uml > default) if I want to use things like printf()! Don't use printf. One call to it will blow out a kernel stack. > The reason why I avoided making threads is because I wanted to use the > windows debug API instead of ptrace(). The debug API requires separate processes? Jeff |
From: Chandan K. <ch...@to...> - 2002-05-10 14:51:55
Attachments:
log.root_fs
|
Hello! I am attaching the log file which shows that now it runs all the way till it tries to mount root fs !! I cleaned up a lot of mess and coded support for the clone(), kernel_thread(), etc. to work on windows. I am setting the stack for the win32 threads myself and that works fine :) At this point I have quite a few threads up running, being scheduled etc. (context_thread, bdflush, kswapd, ksoftirqd, etc) Looks like when the bread() eventually calls __get_request_wait(), it puts itself on the UBD filesystems queue and waits on the wait queue to read the super block. Seems like no one is actually doing the read, nor waking up this thread. Looking at ubd_user.c I can see that we start a io_thread() which reads from kernel_fd socket pair and waits for a request. I dont see any reference to the kernel_fd anywhere else in the code. How does this work? How does the ubd io_thread get invoked and where does it wake up the requesting thread? Also, few hiccups along the way: ubd_init() hung in write_lock, and once the stdio_init() was called, printk's stopped coming to the console. I am working on these. Cheers, Chandan On Tue, 7 May 2002, Jeff Dike wrote: > ch...@to... said: > > The complication is that win32 CreateThread() doesnt take the stack > > pointer as an argument .. arghh. > > You absolutely need to be able to specify the stack. How can a create stack > interface not take a stack argument anyway? Does it find some free address > space by itself for the stack? > > > But it seems like I can set the stack of a thread by SetThreadContext) > > even though it seems to expect enormous stack size (4 times the uml > > default) if I want to use things like printf()! > > Don't use printf. One call to it will blow out a kernel stack. > > > The reason why I avoided making threads is because I wanted to use the > > windows debug API instead of ptrace(). > > The debug API requires separate processes? > > Jeff > |
From: Chandan K. <ch...@to...> - 2002-05-19 00:49:19
|
I have put up the patches for the current UML win32 at: http://toad.net/~chandan/umlwin32/ Let me know if you run into problems. Cheers, -Chandan On Sat, 18 May 2002, Mitch Wright wrote: > Hello Chandan, > > I'm interested in this port. Does this all build in cygwin? Could I get a > tar ball of your stuff? > > Thanks, Mitch Wright > > > ----- Original Message ----- > From: "Chandan Kudige (by way of Mitch Wright <me...@sw...>)" > <ch...@to...> > To: <mit...@ea...> > Sent: Saturday, May 18, 2002 7:45 AM > Subject: Re: [uml-devel] UML on win32 - some thoughts > > > > > > Infact it comes up pretty coolly until it tries to do a context switch > > > > when it spawns the init process and then it crashes :) > > > > > > Is it really at the first context switch or is it at the first call to > > > kernel_thread()? > > > > It did crash in kernel_thread() (inside do_fork() actually, when it tried > > to access current->user). > > > > I then put in the kludge for current and it went all the to the cpu_idle() > > and crashed in schedule(). But that doesnt count! > > > > I now understand the 'current' business and know whnat needs to be done on > > windows. The complication is that win32 CreateThread() doesnt take the > > stack pointer as an argument .. arghh. > > > > But it seems like I can set the stack of a thread by SetThreadContext) > > even though it seems to expect enormous stack size (4 times the uml > > default) if I want to use things like printf()! > > > > > The switcheroo business? You can avoid that by making everything > threads > > > running in the same address space. This will also avoid problems with > > > CLONE_FILE. > > > > The reason why I avoided making threads is because I wanted to use the > > windows debug API instead of ptrace(). Looks like that is only trouble, > > and I will stick with threads and thread-debugging APIs which are more > > restrictive. > > > > > > How does the 'current' pointer work? > > > > > > The current task structure is located at the bottom of the kernel stack. > > > So, you get its address by clearing the low 14 bits of any address on > the > > > stack. > > > > > > And it's not a pointer, so there's not really anything to initialize. > > > > Thanks! Its clear now... cool stuff :) > > > > > > > > Also, send in a boot log whenever you've made some noticable progress > :-) > > > > > > > Here is the boot log for a decent run: > > (Its a WinXP with cygwin environment) > > This one crashed in do_fork(). > > If I had a decent text-mode gdb I would have included the stack trace > > too... > > > > ============== boot log ==================== > > > > chandan@ONE-XP /usr/src/uml/linux > > $ ./linux.exe > > CKERNEL debug 1 > > CKERNEL debug 2 > > CKERNEL debug 3 > > CKERNEL debug 4 > > CKERNEL debug 5 > > CKERNEL debug 6 err 0 > > CKERNEL debug 7 > > CKERNEL debug 8 > > CKERNEL debug 9 > > CALLING SIGNALS: sp @ 0x543000 init_task.task @ 0x541000 > > win32_clone() creating thread > > win32_clone() sleeping (child pid 0x750 ... > > Suspending myself pid @ 0xf6ffb0 pid 0xfffffffe ... > > win32_clone() setting stack sp @ 0x543000 stack_size 32784 > > Get context for child 0x750: ESP 0xf6ff54 succ 1 > > Setting context for child 0x750: ESP 0x54abf0 > > SetThreadContext returned 1 > > Resuming myself pid @ 0xf6ffb0 pid 0xfffffffe ... > > signal_tramp() calling proc @ 0x506fe0 > > ==== ckcurrent @ 0x548000 ==== > > lock_kernel.3080: current @ 0x548000 lock_depth 1 > > Linux version 2.4.18-20um (chandan@ONE-XP) (gcc version 2.95.3-5 (cygwin > > specia > > )) #88 SMP Mon May 6 23:54:54 2002 > > On node 0 totalpages: 8192 > > zone(0): 0 pages. > > zone(1): 8192 pages. > > zone(2): 0 pages. > > Kernel command line: root=/dev/ubd0 > > Calibrating delay loop... 0.42 BogoMIPS > > Memory: 32244k available > > Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) > > Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) > > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > > Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) > > Page-cache hash table entries: 8192 (order: 3, 32768 bytes) > > /proc/cpuinfo not available - skipping CPU capability checks > > check_sigio() Unimplemented > > POSIX conformance testing by UNIFIX > > All CPUs are go! > > Waiting on wait_init_idle (map = 0x0) > > All processors have done init_idle > > > > > > chandan@ONE-XP /usr/src/uml/linux > > $ > > > > > > > > _______________________________________________________________ > > > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > > the hardware. You get the recognition. Email Us: ban...@so... > > _______________________________________________ > > User-mode-linux-devel mailing list > > Use...@li... > > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel > > > |
From: Jeff D. <jd...@ka...> - 2002-05-19 03:18:36
|
ch...@to... said: > I have put up the patches for the current UML win32 at: http:// > toad.net/~chandan/umlwin32/ Cool. Some comments: It would be helpful if you could shrink the patch by configuring out everything you don't need right now and dropping the original files back in. That would drop all the driver stuff that doesn't work out of the patch, which would make it easier for me to figure out what core stuff needs to change. It is apparently possible to mmap on page boundaries on Windows. See http://www.geocrawler.com/archives/3/709/2001/9/0/6662706/ and http://www.geocrawler.com/archives/3/709/2001/9/0/6664156/ Cygwin seems not to have the 64-bit file interfaces. Could we just go straight to whatever Windows has for 64-bit interfaces? There are two implementations of modify_ldt in the patch. Ultimately, the Windows-specific stuff (what's in uml_win32.c in particular), will go off in a separate part of the pool. My current plan is to stick all the non-OS-portable stuff under arch/um/os. So, Linux-specific stuff would go in arch/um/os/linux (which would become arch/um/os/posix/linux when there are multiple Unix ports), and Windows stuff would go under arch/um/os/windows. Jeff |
From: Chandan K. <ch...@to...> - 2002-05-19 15:28:44
|
> It would be helpful if you could shrink the patch by configuring out everything > you don't need right now and dropping the original files back in. That > would drop all the driver stuff that doesn't work out of the patch, which > would make it easier for me to figure out what core stuff needs to change. Good idea. It would also make it easy for me to keep uml-win32 up-to-date with the latest uml patches. > > It is apparently possible to mmap on page boundaries on Windows. See > http://www.geocrawler.com/archives/3/709/2001/9/0/6662706/ > and http://www.geocrawler.com/archives/3/709/2001/9/0/6664156/ > Cool!! This is great, because right now I am changing the default PAGE_SIZE to 64K (yuck) and rebuilding the init to have sections aligned to 64k using the cool kickerelf tools. But it would be very nice to have 4K pages and be able to load native linux binaries. > Cygwin seems not to have the 64-bit file interfaces. Could we just go > straight to whatever Windows has for 64-bit interfaces? No problem. I have faced this with other APIs too. One just needs to declare these functions as pointers and do a GetProcAddress() on the right DLL (usually kernel32.dll) in the beginning. > Ultimately, the Windows-specific stuff (what's in uml_win32.c in particular), > will go off in a separate part of the pool. My current plan is to stick > all the non-OS-portable stuff under arch/um/os. So, Linux-specific stuff > would go in arch/um/os/linux (which would become arch/um/os/posix/linux when > there are multiple Unix ports), and Windows stuff would go under > arch/um/os/windows. Okay, this was my next question. I realised, when I tried building ulm-win32 on a linux cross-compiler that we are right now using the cygwin posix interface heavily. I am going to move over all that to native win32 and probably we can have a generic layer of functions which are called by arch/um/kernel, arch/um/driver etc. Any new port just needs to stick in the OS-layer and be done with it. Chandan |
From: Jeff D. <jd...@ka...> - 2002-05-19 16:58:31
|
ch...@to... said: > But it would be very nice to have 4K pages and be able to load native > linux binaries. Yup. If that doesn't work, then it would severely hurt UML's chances of becoming the universal development and execution environment. > No problem. I have faced this with other APIs too. One just needs to > declare these functions as pointers and do a GetProcAddress() on the > right DLL (usually kernel32.dll) in the beginning. Why not just call the functions? > I am going to move over all that to native win32 Good. > and probably we can > have a generic layer of functions which are called by arch/um/kernel, > arch/um/driver etc. Yup. > Any new port just needs to stick in the OS-layer > and be done with it. Yup. Doing this will probably give you better performance as well. Jeff |
From: Erik P. <epa...@cs...> - 2002-05-19 17:09:48
|
On Sun, May 19, 2002 at 01:01:29PM -0500, Jeff Dike wrote: > > > No problem. I have faced this with other APIs too. One just needs to > > declare these functions as pointers and do a GetProcAddress() on the > > right DLL (usually kernel32.dll) in the beginning. > > Why not just call the functions? > You can't - they're not in a library that you can link with at compile-time. Welcome to Win32. -Erik |
From: Dan A. <da...@gm...> - 2002-05-20 16:33:26
|
On Sat, May 18, 2002 at 11:21:18PM -0500, Jeff Dike wrote: > ch...@to... said: > > I have put up the patches for the current UML win32 at: http:// > > toad.net/~chandan/umlwin32/ > [snip] > > It is apparently possible to mmap on page boundaries on Windows. See > http://www.geocrawler.com/archives/3/709/2001/9/0/6662706/ > and http://www.geocrawler.com/archives/3/709/2001/9/0/6664156/ According to my understanding (and some documents in MSDN), the function mentioned in the post above (ZwMapViewOfSection) is an NT kernel function. Can it be called from userspace somehow? If not, UML-Win32 needs to have a NT kernel support driver or something like that. And it's not just about simple memory mapping. Digging a bit more about this set of functions (Zw*), shows that with these it is possible to attach the same "section" of memory in different processes, and allow child processes to inherit them. Maybe this can be used to easily implement fork() on NT. These memory sections remind me of vm_area_struct's in Linux. -- Dan Aloni da...@gm... |
From: Chandan K. <ch...@to...> - 2002-05-20 18:06:57
|
Looking at the API documentation for ZwMapViewOfSection, the two parameters BaseAddress and SectionOffset are described as: BaseAddressPoints to a variable that will receive the base address of the view. If the initial value of this argument is nonNULL, the view is allocated starting at the specified virtual address rounded down to the next 64-kilobyte address boundary. SectionOffsetPoints to the offset, in bytes, from the beginning of the section to the view. If this pointer is nonNULL, the given value is rounded down to the next allocation granularity size boundary. This seems to indicate that the granularity is again 64K chunks ... Is there a way to specify that it should be 4K pages? Also, is the WinDDK free downloadable ? Are there any licensing issues if we use it with GPL ? I also noticed that there are Mm* functions (MmAllocateContiguousMemory and MmMapLockedPages) which seem to do something similiar. Is anyone aware of these routines? They seem to work on pages. Chandan On Mon, 20 May 2002, Dan Aloni wrote: > On Sat, May 18, 2002 at 11:21:18PM -0500, Jeff Dike wrote: > > ch...@to... said: > > > I have put up the patches for the current UML win32 at: http:// > > > toad.net/~chandan/umlwin32/ > > > [snip] > > > > It is apparently possible to mmap on page boundaries on Windows. See > > http://www.geocrawler.com/archives/3/709/2001/9/0/6662706/ > > and http://www.geocrawler.com/archives/3/709/2001/9/0/6664156/ > > According to my understanding (and some documents in MSDN), the function > mentioned in the post above (ZwMapViewOfSection) is an NT kernel function. > > Can it be called from userspace somehow? If not, UML-Win32 needs to have a > NT kernel support driver or something like that. > > And it's not just about simple memory mapping. Digging a bit more about this > set of functions (Zw*), shows that with these it is possible to attach the > same "section" of memory in different processes, and allow child processes > to inherit them. Maybe this can be used to easily implement fork() on NT. > These memory sections remind me of vm_area_struct's in Linux. > > -- > Dan Aloni > da...@gm... > |
From: Dan A. <da...@gm...> - 2002-05-20 19:04:58
|
On Mon, May 20, 2002 at 02:06:38PM -0400, Chandan Kudige wrote: > Looking at the API documentation for ZwMapViewOfSection, the two > parameters BaseAddress and SectionOffset are described as: > [snip] > This seems to indicate that the granularity is again 64K chunks ... > Is there a way to specify that it should be 4K pages? Carbon copied to Erik Paulson. > Also, is the WinDDK free downloadable ? Are there any licensing issues if > we use it with GPL ? It is freely downloadable from www.microsoft.com (around 80MB, so I hope you got a fast connection). About licensing issues, I have no idea. -- Dan Aloni da...@gm... |
From: Henrik N. <hn...@ma...> - 2002-05-20 22:04:43
|
On Monday 20 May 2002 20:06, Chandan Kudige wrote: > Also, is the WinDDK free downloadable ? Are there any licensing > issues if we use it with GPL ? The specific DDK for 2000, NT and WIN98 is downloadable from MSDN <http://www.microsoft.com/ddk/> in whole or parts. The XP DDK requires a MSDN subscription. Licensing questions is icky when using commercial software in GPL development.. but I don't think you will need to use the DDK at all here, except possibly as a reference on how these functions work in addition to what is published on MSDN. Regards Henrik |
From: Henrik N. <hn...@ma...> - 2002-05-20 22:04:43
|
On Monday 20 May 2002 20:06, Chandan Kudige wrote: > This seems to indicate that the granularity is again 64K chunks ... > Is there a way to specify that it should be 4K pages? The original poster referred to a AT_ROUND_TO_PAGE option, but I cannot find any such option in DDK or SDK.. (searched the 2000 DDK headers, MSDN and the net..) Regards Henrik |
From: Henrik N. <hn...@ma...> - 2002-05-20 22:04:48
|
From my understanding these are just kernel-level entrypoints to their corresponding executive services/calls. Meaning, for each ZwXXX there should be a corresponding userspace executive service/call. These are exported by ntdll.dll. Quote from MSDN: The ZwXxx routines provide a set of system entry points parallel to some of the executive's system services. A call to a ZwXxx routine from kernel-mode code results in a call to the corresponding system service. Now, as Microsoft do not document the executive services, only the public WIN32 calls and the kernel-mode DDK calls, one has to rely on the ZwXXX documentation for the actual powers of these executive services. The interface should be the same when called from user-space as when called from kernel-space. See also http://www.sysinternals.com/ntw2k/info/ntdll.shtml for more information. Regards Henrik On Monday 20 May 2002 18:29, Dan Aloni wrote: > On Sat, May 18, 2002 at 11:21:18PM -0500, Jeff Dike wrote: > > ch...@to... said: > > > I have put up the patches for the current UML win32 at: http:// > > > toad.net/~chandan/umlwin32/ > > [snip] > > > It is apparently possible to mmap on page boundaries on Windows. > > See http://www.geocrawler.com/archives/3/709/2001/9/0/6662706/ > > and http://www.geocrawler.com/archives/3/709/2001/9/0/6664156/ > > According to my understanding (and some documents in MSDN), the > function mentioned in the post above (ZwMapViewOfSection) is an NT > kernel function. > > Can it be called from userspace somehow? If not, UML-Win32 needs to > have a NT kernel support driver or something like that. > > And it's not just about simple memory mapping. Digging a bit more > about this set of functions (Zw*), shows that with these it is > possible to attach the same "section" of memory in different > processes, and allow child processes to inherit them. Maybe this > can be used to easily implement fork() on NT. These memory sections > remind me of vm_area_struct's in Linux. |
From: Chandan K. <ch...@to...> - 2002-05-21 14:45:35
|
Hi Henrik, It was not clear for MS documentation that we can call the ZwXYZ routines from user-space. I can import these symbols from ntdll.dll at runtime, but looks like for invoking the functions atleast the header files from DDK are needed. There are many macros that need to be used to pass as arguments. Even the error codes returned by these APIs are not listed in winerrors.h. So I guess I have to download the DDK anyway. Chandan On Mon, 20 May 2002, Henrik Nordstrom wrote: > >From my understanding these are just kernel-level entrypoints to > their corresponding executive services/calls. > > Meaning, for each ZwXXX there should be a corresponding userspace > executive service/call. These are exported by ntdll.dll. > > Quote from MSDN: > The ZwXxx routines provide a set of system entry points parallel to > some of the executive's system services. A call to a ZwXxx routine > from kernel-mode code results in a call to the corresponding system > service. > > Now, as Microsoft do not document the executive services, only the > public WIN32 calls and the kernel-mode DDK calls, one has to rely on > the ZwXXX documentation for the actual powers of these executive > services. The interface should be the same when called from > user-space as when called from kernel-space. > > See also http://www.sysinternals.com/ntw2k/info/ntdll.shtml for more > information. > > Regards > Henrik > > > On Monday 20 May 2002 18:29, Dan Aloni wrote: > > On Sat, May 18, 2002 at 11:21:18PM -0500, Jeff Dike wrote: > > > ch...@to... said: > > > > I have put up the patches for the current UML win32 at: http:// > > > > toad.net/~chandan/umlwin32/ > > > > [snip] > > > > > It is apparently possible to mmap on page boundaries on Windows. > > > See http://www.geocrawler.com/archives/3/709/2001/9/0/6662706/ > > > and http://www.geocrawler.com/archives/3/709/2001/9/0/6664156/ > > > > According to my understanding (and some documents in MSDN), the > > function mentioned in the post above (ZwMapViewOfSection) is an NT > > kernel function. > > > > Can it be called from userspace somehow? If not, UML-Win32 needs to > > have a NT kernel support driver or something like that. > > > > And it's not just about simple memory mapping. Digging a bit more > > about this set of functions (Zw*), shows that with these it is > > possible to attach the same "section" of memory in different > > processes, and allow child processes to inherit them. Maybe this > > can be used to easily implement fork() on NT. These memory sections > > remind me of vm_area_struct's in Linux. > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel > |