Date: Fri, 26 Nov 1999 17:31:13 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Jake Burkholder <jburkhol@home.com> Cc: arch@freebsd.org, "Daniel M. Eischen" <eischen@vigrid.com> Subject: Re: Threads stuff Message-ID: <Pine.BSF.4.10.9911261717180.544-100000@current1.whistle.com> In-Reply-To: <19991127011344.156031FDA@24.66.174.118.bc.wave.home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 26 Nov 1999, Jake Burkholder wrote: > > > OK, so the int 0x80 trap does switch segment registers and we > > > are already on the kernel stack by the time that int0x80_syscall > > > is entered? > > > > That is my belief > > Yes, that's right. A good reference for this is the Intel > Architecture Software Developer's Manual: > > http://developer.intel.com/design/pentiumIII/xeon/manuals/ Wonderful, I knew someone would point me at an online version :-) > > volumes 2 and 3 are most useful. > > 'int' loads the new ss and esp (kernel stack) from the TSS and > then push a far pointer to the old (user) stack, eflags, a far > pointer to the return address, and an error code on to that stack. > > I agree that it would be useful to have the context saved in userland, > and it doesn't seem that hard to do so. Restarting system calls would > have to be handled differently. > > > When the syscall blocks, the saved information above is to be turned into > > a full frame. The PC (eip) is added (pointing to where we want it to > > resume when the IO completes) and the thread is set up looking as though > > it's waiting on it's IO completion block. Actualy thinking about it.. the userland might as well do a setjmp() (or something that looks a lot like it) as it needs to save everything and that seems to be a good way.. does setjmp save %ds %es etc? > > Is an IO completion block just a data structure that allows > the UTS to keep track of threads in the kernel? Basically as I see it, a new thread starts out with a new stack. Before it gets to start running, a number of things are pushed onto that stack. This means that every thread has one.. this is basically the thread local storage.. (how it FINDS it is another matter). In any case, teh IO completeion block is one of the things there. Every syscall that is altered, uses this to pass the completion code, the return values and the errno value back. It also contains a mutex. How we FIND this thread local storage is a completely different problem. Under Mach threads the stacks were limitted to (from memory) 60KB each with a 1 page guard page allocated above each to protect it from the previous one. that the thread local storage was easily found as: %esp & 0xffff000 - 1024 where 1024 was the space allocated to it. > > > On completion of the IO, the io completion block is updated > > just as it would have been had the syscall not blocked, and > > The UTS is notified that the IO has completed, and updates the > completion block. Is that right? No the kernel updtes the completion block. just before queueing tself for notification to the UTS. > > When a thread does a system call, does it first call a scheduler > routine that creates the IO completion block? (part of the new > system call gate?) No it has one permanently assiged. (though your idea would work) > > > the KSE is hung off the subprocess. When the subprocess is next run, > [...] > > with mirrors, (and a little creative stack surgery). > > Yeah, this sounds interesting. > > Thanks for forwarding this stuff to the list! > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911261717180.544-100000>