From: Nathan L. <lut...@li...> - 2002-09-11 01:06:04
|
Changed the subject because this doesn't really pertain to UML/SPARC. On Tue, Sep 10, 2002 at 06:29:19PM -0500, Jeff Dike wrote: > lut...@li... said: > > That interrupt a thread's execution and send it off into a handler > > routine? No. >=20 > Hmmm, I find that slightly unbelievable. Oh well. I was really surprised too when I couldn't come up with anything after=20 poring over the Win32 API documentation. But then I read through the=20 Cygwin internals, and I figure they'd be using a better method if one=20 existed. > > I guess I could avoid the locking issue by allowing the polling thread > > to suspend the running process when a signal comes in, calling the > > handler in the polling thread, then resuming the currently-running > > process. > > A potential problem there is that some handlers want to refer to current, > which in 2.4 is at the base of the stack, and whose address is calculated > by zeroing the low bits of a convenient stack address. How many handlers do this? I can't think of a good reason why an interrupt handler should need to know what task was running on the current CPU. (I must be wrong; tell me what I'm missing.) > In 2.5, things are simpler, since there's a thread_info struct on the sta= ck > which points to current. It wouldn't surprise me if umlwin32 ended up being in 2.5 only. There's a= =20 long ways to go before it's functional, much less stable and usable. In related news, the CIPE ethertap driver is working fine with umlwin32=20 and can send and receive packets. The TCP/IP stack appears to be working= =20 correctly, although I haven't tested it with more than ARP and ping. The downside is that there doesn't seem to be an easy way to pass file handles between win32 processes. However, handles can be inherited, so all processes can access the handles if the handles are created within the root kernel thread before any user processes. But then the interrupt handling can't happen in the cpu_idle process because the idle process gets created before the network initialization happens, so I need to split= =20 off a separate I/O thread near the end of the kernel init sequence. Ah, if only Windows had CLONE_FILES! -Nathan --=20 Help reduce spam! PGP-sign your email. |
From: Jeff D. <jd...@ka...> - 2002-09-11 02:10:33
|
lut...@li... said: > I was really surprised too when I couldn't come up with anything after > poring over the Win32 API documentation. But then I read through the > Cygwin internals, and I figure they'd be using a better method if one > existed. So how do you handle asynchronous events on Windows? You create a whole new thread to poll for them, and there's nothing else? > How many handlers do this? The page fault handler for sure. Also, SIGTRAP, SIGILL, SUGBUS. The timer does too, because it can reschedule. The others shouldn't. > However, handles can be inherited, so all processes can access the > handles if the handles are created within the root kernel thread > before any user processes. This can't work, and the idle process/network initialization order is the least of your problems. A ubd file will be opened in the context of the mount process, which is not the parent of anything. A subsequent ls process will need access to that handle, in spite of having, at best, a sibling relationship to the mount. > Ah, if only Windows had CLONE_FILES! Yeah. My plan for that (which you are free to implement :-) is to make all file accesses go through a single interface, which checks for EBADF or the local equivalent, and does the local equivalent of open(), dup2() to get that descriptor opened properly in that process. The open piece of that interface would add an entry to a table saying 'fd #n is opened to file foo'. This will work for the Unixes that don't have CLONE_FILE. Will it work for Windows, given your earlier statement that its file handles aren't integers? That was my original plan. I have a new plan stemming from the redesign. The UML kernel will be in its own address space, rather than in multiple process address spaces. Then, all file opens and accesses happen in the context of that one process, and the need for CLONE_FILE disappears. This would tie you to the new UML, which may be good, bad, or irrelevant. Jeff |
From: Nathan L. <lut...@li...> - 2002-09-11 18:52:51
|
On Tue, Sep 10, 2002 at 10:13:53PM -0500, Jeff Dike wrote: > So how do you handle asynchronous events on Windows? You create a whole > new thread to poll for them, and there's nothing else? Yup. You got it. As far as I can tell, that seems to be The Way to do=20 aio on Windows. Windows is really big on using lots of threads... > The page fault handler for sure. Also, SIGTRAP, SIGILL, SUGBUS. The tim= er > does too, because it can reschedule. These are fine; page faults and other exceptions like it are handled by the low-level Windows exception system. umlwin32 uses the (undocumented) = =20 mechanism that Cygwin uses to trap these and dispatch handling functions within the same thread. Not sure about the timer though; this is yet unimplemented and may need special consideration. I was only worried about I/O device driver interrupts, which I can't imagine would need to access the current process for any reason. > A ubd file will be opened in the context of the mount process, which is n= ot > the parent of anything. A subsequent ls process will need access to that > handle, in spite of having, at best, a sibling relationship to the mount. I was wrong about not being able to pass handles; it seems the DuplicateHandle() function can create new handles in a different process. = =20 So, this particular issue can be fixed by using DuplicateHandle() to move the handle to the root kernel process. The existing child processes still won't have access to it though, so we'll have to use your trick: > My plan for that (which you are free to implement :-) is to make all > file accesses go through a single interface, which checks for EBADF or the > local equivalent, and does the local equivalent of open(), dup2() to get > that descriptor opened properly in that process. The open piece of that > interface would add an entry to a table saying 'fd #n is opened to file f= oo'. I think this will be what I have to do. Every process will have a local=20 table of handles, and there will be a global table of handles that are=20 valid in the root thread only. Handles will be referenced by their index= =20 into the handle table, which conveniently means we can continue to refer=20 to handles as ints. Threads will be responsible for calling=20 DuplicateHandle() to maintain their access to all the handles accessible=20 by the kernel. I'll do that this afternoon. > The UML kernel will be in its own address space, rather than in multiple > process address spaces. Then, all file opens and accesses happen in the > context of that one process, and the need for CLONE_FILE disappears. Eventually we'll need to move to an architecture similar to what's being implemented in the Great Redesign, where all of the host resources are manipulated within a single kernel process. I don't think we'll be able to completely extract the kernel from the user processes, since I'm not sure there's a way to externally manipulate a process's VM, even using the debugging functions. That's a ways off though. -Nathan --=20 Help reduce spam! PGP-sign your email. |