Re: JKH Project: x86: pcb_ext
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 <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
"Andrew R. Reiter" wrote: > On Wed, 19 Sep 2001, Peter Wemm wrote: > : > :One comment: > : > :-cmpl$0, PCB_USERLDT(%edx) /* if there is one */ > :+movlTD_PROC(%ecx), %eax /* load struct proc from CURTHREAD */ > :+lealP_MD(%eax), %eax/* get mdproc from proc */ > :+cmpl$0, MD_LDT(%eax)/* if there is one */ > : > : > :This can be written as: > : movlTD_PROC(%ecx), %eax > : cmpl$0, P_MD+MD_LDT(%eax) > : > :This is evaluated at assemble time. > > Yea, Kinda dumb on my part :-/ No, I just happened to miss the same shortcut recently, so I noticed it. :-) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
Peter,
Attached is the fix wrt your previous email. Again, can be found in
www.watson.org/~arr/fbsd-patches/
Cheers,
Andrew
--- include/pcb.h.orig Wed Sep 19 02:07:48 2001
+++ include/pcb.h Wed Sep 19 02:08:37 2001
@@ -61,7 +61,6 @@
int pcb_dr6;
int pcb_dr7;
- struct pcb_ldt *pcb_ldt; /* per process (user) LDT */
union savefpu pcb_save;
u_char pcb_flags;
#defineFP_SOFTFP 0x01/* process using software fltng pnt emulator
*/
--- include/pcb_ext.h.orig Wed Sep 19 02:07:54 2001
+++ include/pcb_ext.h Wed Sep 19 02:10:37 2001
@@ -43,20 +43,9 @@
struct vm86_kernel ext_vm86; /* vm86 area */
};
-struct pcb_ldt {
- caddr_t ldt_base;
- int ldt_len;
- int ldt_refcnt;
- u_long ldt_active;
- struct segment_descriptor ldt_sd;
-};
-
#ifdef _KERNEL
int i386_extend_pcb __P((struct thread *));
-void set_user_ldt __P((struct pcb *));
-struct pcb_ldt *user_ldt_alloc __P((struct pcb *, int));
-void user_ldt_free __P((struct pcb *));
#endif
--- include/proc.h.orig Wed Sep 19 02:07:59 2001
+++ include/proc.h Wed Sep 19 03:28:55 2001
@@ -38,6 +38,15 @@
#define_MACHINE_PROC_H_
#include
+#include
+
+struct proc_ldt {
+caddr_t ldt_base;
+int ldt_len;
+int ldt_refcnt;
+u_long ldt_active;
+struct segment_descriptor ldt_sd;
+};
/*
* Machine-dependent part of the proc structure for i386.
@@ -46,6 +55,15 @@
};
struct mdproc {
+ struct proc_ldt *md_ldt;/* per-process ldt */
};
+
+#ifdef _KERNEL
+
+void set_user_ldt __P((struct mdproc *));
+struct proc_ldt *user_ldt_alloc __P((struct mdproc *, int));
+void user_ldt_free __P((struct thread *));
+
+#endif /* _KERNEL */
#endif /* !_MACHINE_PROC_H_ */
--- i386/genassym.c.origWed Sep 19 02:16:34 2001
+++ i386/genassym.c Wed Sep 19 13:03:45 2001
@@ -63,6 +63,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,7 @@
#include
#include
#include
+#include
ASSYM(P_VMSPACE, offsetof(struct proc, p_vmspace));
ASSYM(VM_PMAP, offsetof(struct vmspace, vm_pmap));
@@ -92,6 +94,9 @@
ASSYM(TD_PROC, offsetof(struct thread, td_proc));
ASSYM(TD_INTR_NESTING_LEVEL, offsetof(struct thread, td_intr_nesting_level));
+ASSYM(P_MD, offsetof(struct proc, p_md));
+ASSYM(MD_LDT, offsetof(struct mdproc, md_ldt));
+
ASSYM(KE_FLAGS, offsetof(struct kse, ke_flags));
ASSYM(KEF_ASTPENDING, KEF_ASTPENDING);
@@ -126,7 +131,6 @@
ASSYM(PCB_EIP, offsetof(struct pcb, pcb_eip));
ASSYM(TSS_ESP0, offsetof(struct i386tss, tss_esp0));
-ASSYM(PCB_USERLDT, offsetof(struct pcb, pcb_ldt));
ASSYM(PCB_GS, offsetof(struct pcb, pcb_gs));
ASSYM(PCB_DR0, offsetof(struct pcb, pcb_dr0));
ASSYM(PCB_DR1, offsetof(struct pcb, pcb_dr1));
--- i386/machdep.c.orig Wed Sep 19 02:16:39 2001
+++ i386/machdep.c Wed Sep 19 04:57:31 2001
@@ -103,6 +103,7 @@
#include
#include
#include/* pcb.h included via sys/user.h */
+#include
#include
#ifdef PERFMON
#include
@@ -880,8 +881,8 @@
struct trapframe *regs = td->td_frame;
struct pcb *pcb = td->td_pcb;
- if (pcb->pcb_ldt)
- user_ldt_free(pcb);
+ if (td->td_proc->p_md.md_ldt)
+ user_ldt_free(td);
bzero((char *)regs, sizeof(struct trapframe));
regs->tf_eip = entry;
--- i386/swtch.s.orig Wed Sep 19 02:16:14 2001
+++ i386/swtch.sThu Sep 20 03:51:55 2001
@@ -246,7 +246,8 @@
/* XXX FIXME: we should be restoring the local APIC TPR */
#endif /* SMP */
- cmpl$0, PCB_USERLDT(%edx) /* if there is one */
+ movlTD_PROC(%ecx), %eax /* load struct proc from CURTHREAD */
+ cmpl$0, P_MD+MD_LDT(%eax) /* see if md_ldt == 0 */
jnz 1f /* then use it */
movl_default_ldt,%eax /* We will use the default */
cmplPCPU(CURRENTLDT),%eax /* check to see if already loaded */
@@ -255,9 +256,11 @@
movl%eax,PCPU(CURRENTLDT) /* store what we have */
jmp 2f
-1: pushl %edx/* call a non-trusting routine */
- callset_user_ldt/* to check and load the ldt */
- popl%edx
+1: pushl %edx/* save edx */
+ pushl P_MD+MD_LDT(%eax) /* passing p_md -> set_user_ldt */
+ callset_user_ldt/* check and load the ldt */
+ popl%eax/* get p_md off stack */
+ popl%edx/* restore edx */
2:
/* This must be done after loading the user LDT. */
--- i386/sys_machdep.c.orig Wed Sep 19 02:16:22 2001
+++ i386/sys_machdep.c Wed Sep 19 04:34:30 2001
@@ -
Re: JKH Project: x86: pcb_ext
On Wed, 19 Sep 2001, Peter Wemm wrote: : :One comment: : :- cmpl$0, PCB_USERLDT(%edx) /* if there is one */ :+ movlTD_PROC(%ecx), %eax /* load struct proc from CURTHREAD */ :+ lealP_MD(%eax), %eax/* get mdproc from proc */ :+ cmpl$0, MD_LDT(%eax)/* if there is one */ : : :This can be written as: : movlTD_PROC(%ecx), %eax : cmpl$0, P_MD+MD_LDT(%eax) : :This is evaluated at assemble time. Yea, Kinda dumb on my part :-/ : :And this change: :movl %eax,PCPU(CURRENTLDT) /* store what we have */ : jmp 2f : :-1:pushl %edx/* call a non-trusting routine */ :+1:pushl %eax/* call a non-trusting routine */ : callset_user_ldt/* to check and load the ldt */ :- popl%edx :+ popl%eax : 2: : :is not good.. you still need to save %edx since set_user_ldt is free :to trash it (%edx is the secondary return value from a C function). : Hmm interesting. Thanks. :eg: :0xc02e75c4 : mov0x10(%ebx),%edx :0xc02e75c7 : mov%edx,(%eax,%ecx,1) :0xc02e75ca : mov0x14(%ebx),%edx :0xc02e75cd : mov%edx,0x4(%eax,%ecx,1) : :The code after this in swtch.s depends on %edx being preserved. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] :"All of this is for nothing if we don't go to the stars" - JMS/B5 : : *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
"Andrew R. Reiter" wrote: > On Wed, 19 Sep 2001, Julian Elischer wrote: > > :> > :> 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? > : > > LDT is per process therefore, in the patch I made, I moved pcb_ldt out > of struct pcb and into mdproc (which is in struct proc). > > I've asked Peter to take a look at it and jhb, however, it is located at: > http://www.watson.org/~arr/fbsd-patches/ldt-2-mdproc.diff One comment: - cmpl$0, PCB_USERLDT(%edx) /* if there is one */ + movlTD_PROC(%ecx), %eax /* load struct proc from CURTHREAD */ + lealP_MD(%eax), %eax/* get mdproc from proc */ + cmpl$0, MD_LDT(%eax)/* if there is one */ This can be written as: movlTD_PROC(%ecx), %eax cmpl$0, P_MD+MD_LDT(%eax) This is evaluated at assemble time. And this change: movl%eax,PCPU(CURRENTLDT) /* store what we have */ jmp 2f -1: pushl %edx/* call a non-trusting routine */ +1: pushl %eax/* call a non-trusting routine */ callset_user_ldt/* to check and load the ldt */ - popl%edx + popl%eax 2: is not good.. you still need to save %edx since set_user_ldt is free to trash it (%edx is the secondary return value from a C function). eg: 0xc02e75c4 : mov0x10(%ebx),%edx 0xc02e75c7 : mov%edx,(%eax,%ecx,1) 0xc02e75ca : mov0x14(%ebx),%edx 0xc02e75cd : mov%edx,0x4(%eax,%ecx,1) The code after this in swtch.s depends on %edx being preserved. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
On Wed, 19 Sep 2001, Julian Elischer wrote: :> :> 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? : LDT is per process therefore, in the patch I made, I moved pcb_ldt out of struct pcb and into mdproc (which is in struct proc). I've asked Peter to take a look at it and jhb, however, it is located at: http://www.watson.org/~arr/fbsd-patches/ldt-2-mdproc.diff Cheers, Andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
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? > > Cheers, > -Peter > -- > Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
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. We still would need to sync LDT reloads.. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
On Wed, 19 Sep 2001, John Baldwin wrote: : :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 are :used for very few things anyways. LDT's are another matter and can be moved :w/o a problem. Currently fixing a bug in my patch for moving ldt -> mdproc (in struct proc), when done I will let you know -- should be mid-day today. Cheers, Andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
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 are used for very few things anyways. LDT's are another matter and can be moved w/o a problem. -- John Baldwin <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
Peter Wemm wrote:
>
> John Baldwin wrote:
> > Here's a Junior Kernel Hacker project for someone:
> >
> > - Move pcb_ext and pcb_ldt out of the pcb of struct thread and into
> > struct mdproc; I.e., you probably want to do something like this:
> > - Rename struct pcb_ext to struct proc_tss and struct pcb_ldt to
> > struct proc_ldt. (Fixup pcb_ext member names to use a tss_
> > prefix instead of ext_)
> > - Have a struct mdproc as so:
> >
> > struct mdproc {
> > struct proc_tss *md_tss;
> > struct proc_ldt *md_ldt;
> > }
> >
> > Prior to KSE this was just annoyance but wasn't an actual problem. With KSE
> > threads are temporary, whereas the ldt and tss are per-process properties
> > that need to stick around.
>
> Just so that somebody doesn't get a nasty suprise.. this is not as
> simple as it sounds.. There are several configurations of "extended" pcb,
> including having a seperate i386tss.. The nasty part is that some of this
> is per-thread because there is a per-thread kernel stack pointer embedded
> in it.
per cpu and per process... this is the domain of the KSE..
It should be duplicated from the 'master' one for each KSE created,
and the appropriate stack pointer shifted into it
when the thread is attached to the KSE to run.
Since KSEs are per processor, there can only be one processor using
each at a time, however there is still a problem with keeping the extensions
UP TO DATE with each others when they are changed... We should be ok, if
changes to the extension are only done via a well defined interface though.
>
> The upshot of this is that there probably needs to be a "master" pcb extension
> that gets propagated to thread children.
>
> In particular, look at these fragmets of swtch.s:
>
> movlPCB_EXT(%edx), %edi /* new tss descriptor */
> [..]
> movl%edx, PCPU(COMMON_TSS) + TSS_ESP0 /* stack is below pcb */
> [..]
> movlPCPU(TSS_GDT), %ebx /* entry in GDT */
> movl0(%edi), %eax
> movl%eax, 0(%ebx)
> movl4(%edi), %eax
> movl%eax, 4(%ebx)
> movl$GPROC0_SEL*8, %esi /* GSEL(entry, SEL_KPL) */
> ltr %si
>
> I think this is actually broken right now since the tss_esp0 is pointing
> to the wrong location.. It's actually pointing to an unmapped page.
>
> And note how we install the per-thread tss extension pointer into the
> per-cpu tss slot in the gdt.
>
> And, sys_machdep.c:
> ext->ext_tss.tss_esp0 = td->td_kstack + ctob(KSTACK_PAGES) -
> sizeof(struct pcb) - 16;
>
> We cannot entirely move the extended tss into into a mdproc since td_kstack
> is different in each thread.
>
> 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.
ah yes.. that's what I said..
>
> Or, we just say "no pcb extensions for kse processes".
I think we can do it.. though what would it be useful for?
(unlikely that Multiple threads would be that useful in emulating
DOS programs.. NT programs, maybe but the addaption layer would be a
nightmare..)
>
> Cheers,
> -Peter
> --
> Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> "All of this is for nothing if we don't go to the stars" - JMS/B5
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +-->x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
John Baldwin wrote:
> Here's a Junior Kernel Hacker project for someone:
>
> - Move pcb_ext and pcb_ldt out of the pcb of struct thread and into
> struct mdproc; I.e., you probably want to do something like this:
> - Rename struct pcb_ext to struct proc_tss and struct pcb_ldt to
> struct proc_ldt. (Fixup pcb_ext member names to use a tss_
> prefix instead of ext_)
> - Have a struct mdproc as so:
>
> struct mdproc {
> struct proc_tss *md_tss;
> struct proc_ldt *md_ldt;
> }
>
> Prior to KSE this was just annoyance but wasn't an actual problem. With KSE
> threads are temporary, whereas the ldt and tss are per-process properties
> that need to stick around.
Just so that somebody doesn't get a nasty suprise.. this is not as
simple as it sounds.. There are several configurations of "extended" pcb,
including having a seperate i386tss.. The nasty part is that some of this
is per-thread because there is a per-thread kernel stack pointer embedded
in it.
The upshot of this is that there probably needs to be a "master" pcb extension
that gets propagated to thread children.
In particular, look at these fragmets of swtch.s:
movlPCB_EXT(%edx), %edi /* new tss descriptor */
[..]
movl%edx, PCPU(COMMON_TSS) + TSS_ESP0 /* stack is below pcb */
[..]
movlPCPU(TSS_GDT), %ebx /* entry in GDT */
movl0(%edi), %eax
movl%eax, 0(%ebx)
movl4(%edi), %eax
movl%eax, 4(%ebx)
movl$GPROC0_SEL*8, %esi /* GSEL(entry, SEL_KPL) */
ltr %si
I think this is actually broken right now since the tss_esp0 is pointing
to the wrong location.. It's actually pointing to an unmapped page.
And note how we install the per-thread tss extension pointer into the
per-cpu tss slot in the gdt.
And, sys_machdep.c:
ext->ext_tss.tss_esp0 = td->td_kstack + ctob(KSTACK_PAGES) -
sizeof(struct pcb) - 16;
We cannot entirely move the extended tss into into a mdproc since td_kstack
is different in each thread.
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".
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
it's fine by me
On Tue, 18 Sep 2001, John Baldwin wrote:
>
> On 18-Sep-01 Julian Elischer wrote:
> > this is already on my list of "non 1:1 fixes needed"
>
> Heh, it was on my todo list for the past few months. :) Andrew Reiter has
> expressed interest in doing this. Do you object to him getting this done and
> freeing us both up for other things or do you wish to do it yourself?
>
> > On Tue, 18 Sep 2001, John Baldwin wrote:
> >
> >> Here's a Junior Kernel Hacker project for someone:
> >>
> >> - Move pcb_ext and pcb_ldt out of the pcb of struct thread and into
> >> struct mdproc; I.e., you probably want to do something like this:
> >> - Rename struct pcb_ext to struct proc_tss and struct pcb_ldt to
> >> struct proc_ldt. (Fixup pcb_ext member names to use a tss_
> >> prefix instead of ext_)
> >> - Have a struct mdproc as so:
> >>
> >> struct mdproc {
> >> struct proc_tss *md_tss;
> >> struct proc_ldt *md_ldt;
> >> }
> >>
> >> Prior to KSE this was just annoyance but wasn't an actual problem. With KSE
> >> threads are temporary, whereas the ldt and tss are per-process properties
> >> that
> >> need to stick around.
> >>
> >> --
> >>
> >> John Baldwin <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
> >> with "unsubscribe freebsd-hackers" in the body of the message
> >>
> >
>
> --
>
> John Baldwin <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
On 18-Sep-01 Julian Elischer wrote:
> this is already on my list of "non 1:1 fixes needed"
Heh, it was on my todo list for the past few months. :) Andrew Reiter has
expressed interest in doing this. Do you object to him getting this done and
freeing us both up for other things or do you wish to do it yourself?
> On Tue, 18 Sep 2001, John Baldwin wrote:
>
>> Here's a Junior Kernel Hacker project for someone:
>>
>> - Move pcb_ext and pcb_ldt out of the pcb of struct thread and into
>> struct mdproc; I.e., you probably want to do something like this:
>> - Rename struct pcb_ext to struct proc_tss and struct pcb_ldt to
>> struct proc_ldt. (Fixup pcb_ext member names to use a tss_
>> prefix instead of ext_)
>> - Have a struct mdproc as so:
>>
>> struct mdproc {
>> struct proc_tss *md_tss;
>> struct proc_ldt *md_ldt;
>> }
>>
>> Prior to KSE this was just annoyance but wasn't an actual problem. With KSE
>> threads are temporary, whereas the ldt and tss are per-process properties
>> that
>> need to stick around.
>>
>> --
>>
>> John Baldwin <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
>> with "unsubscribe freebsd-hackers" in the body of the message
>>
>
--
John Baldwin <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
this is already on my list of "non 1:1 fixes needed"
On Tue, 18 Sep 2001, John Baldwin wrote:
> Here's a Junior Kernel Hacker project for someone:
>
> - Move pcb_ext and pcb_ldt out of the pcb of struct thread and into
> struct mdproc; I.e., you probably want to do something like this:
> - Rename struct pcb_ext to struct proc_tss and struct pcb_ldt to
> struct proc_ldt. (Fixup pcb_ext member names to use a tss_
> prefix instead of ext_)
> - Have a struct mdproc as so:
>
> struct mdproc {
> struct proc_tss *md_tss;
> struct proc_ldt *md_ldt;
> }
>
> Prior to KSE this was just annoyance but wasn't an actual problem. With KSE
> threads are temporary, whereas the ldt and tss are per-process properties that
> need to stick around.
>
> --
>
> John Baldwin <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
JKH Project: x86: pcb_ext
Here's a Junior Kernel Hacker project for someone:
- Move pcb_ext and pcb_ldt out of the pcb of struct thread and into
struct mdproc; I.e., you probably want to do something like this:
- Rename struct pcb_ext to struct proc_tss and struct pcb_ldt to
struct proc_ldt. (Fixup pcb_ext member names to use a tss_
prefix instead of ext_)
- Have a struct mdproc as so:
struct mdproc {
struct proc_tss *md_tss;
struct proc_ldt *md_ldt;
}
Prior to KSE this was just annoyance but wasn't an actual problem. With KSE
threads are temporary, whereas the ldt and tss are per-process properties that
need to stick around.
--
John Baldwin <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
