bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TSS switching


From: Roland McGrath
Subject: Re: TSS switching
Date: Fri, 12 Oct 2001 16:21:28 -0400 (EDT)

> I think I will work on a solution for oskit-mach and forget gnumach for now.
> I have a solution for gnumach ready, but there are bugs and it is more
> difficult to debug than oskit-mach. (I have a second computer do to remote
> debugging now).

:-)  You won't get any argument from me!

> In oskit-mach, the base_tss doesn't have a bitmap at all.  So we need to
> override that with our own base_tss that has a bitmap, it seems.  But in the
> documentation there is an XXX marker that there is also an alternative
> default tss which has a bitmap, but "it isn't fully integrated or documented
> yet" and in fact I couldn't find any traces of it.  Do you know about it?

Yeah, don't believe everything you read in the oskit docs.  In this case
"not fully integrated" might mean it was in somebody's working directory in
Utah in the mid-90s and never got checked in. :-) (What can I say?  When I
worked there I never updated the docs either.)

It's easy enough to either have a different ktss and switch to it, or just
to link-time override the base_tss definition (the oskit puts it in a
separate file to make this easy).  Define a struct somewhere {
        struct x86_tss tss;
        uint8_t bitmap[35536/8];
        uint8_t barrier;
}, make mp_desc.h use that instead of x86_tss, and somewhere stick:

struct mytss ktss;
#pragma base_tss = ktss

It doesn't matter if the bitmap and barrier aren't initialized during
bootup.  It only matters when you go to user mode; at IOPL 0, the bitmap is
not consulted.

Note that we have to adjust the BASE_TSS segment limit and reload (call
base_tss_load) after preparing the bitmap anyway.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]