From owner-freebsd-hackers Thu Sep 20 10:38:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id CEA2C37B40B for ; Thu, 20 Sep 2001 10:38:22 -0700 (PDT) Received: (qmail 50557 invoked from network); 20 Sep 2001 17:38:22 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Sep 2001 17:38:22 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3BA959E7.43CD9CD6@elischer.org> Date: Thu, 20 Sep 2001 10:38:08 -0700 (PDT) From: John Baldwin To: Julian Elischer Subject: Re: JKH Project: x86: pcb_ext Cc: hackers@FreeBSD.org, Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 20-Sep-01 Julian Elischer wrote: > Peter Wemm wrote: >> >> John Baldwin wrote: >> > >> > On 19-Sep-01 Peter Wemm wrote: >> > > The more I think about it, the right place may be the kse, since that >> > > outlives >> > > the threads and is per-cpu unlike the process. >> > > >> > > Or, we just say "no pcb extensions for kse processes". >> > >> > Each thread would need its own TSS, and to preserve existing semantics, we >> > would have to change the TSS of all threads for each TSS related syscall. >> > In >> > light of that, I vote in favor of "no TSS's for kse processes" since TSS's >> > ar >> e >> > used for very few things anyways. LDT's are another matter and can be >> > moved >> > w/o a problem. >> >> The main two things we seem to use the per-process TSS stuff for are: >> Fine grained IO port permission bitmap >> VM86 mode >> I think we can well do without the complexity of mixing KSE with those two. > > > I could IMAGINE a vm86 version that ran the control/exception > thread on another processor as a different thread. (though who would write > it?) > I could also imagine a muli-threaded program doing IO to a device as a > userland > driver. > > but of course hey'd need to be writen explicitly for it.. > >> >> We still would need to sync LDT reloads.. > > that's more of a worry for me. > Do we still have separate a LDT for threads? What you will have to do for the LDT reload (an LDT is per-process, not per-thread) is perform a context switch (or possibly just a LDT reload) on all processors running threads from thsi process. We already do this in a way when we change an LDT that is shared, IIRC. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message