Date: Fri, 26 Nov 1999 17:13:43 -0800 From: Jake Burkholder <jburkhol@home.com> To: Julian Elischer <julian@whistle.com> Cc: arch@freebsd.org, "Daniel M. Eischen" <eischen@vigrid.com> Subject: Re: Threads stuff Message-ID: <19991127011344.156031FDA@24.66.174.118.bc.wave.home.com> In-Reply-To: Your message of "Fri, 26 Nov 1999 15:37:58 PST." <Pine.BSF.4.10.9911261503050.544-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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/ 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. Is an IO completion block just a data structure that allows the UTS to keep track of threads in the kernel? > 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? 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?) > 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?19991127011344.156031FDA>