Date: Tue, 9 Jul 2002 11:43:53 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: John Baldwin <jhb@FreeBSD.org>, proven@proven.org, FreeBSD current users <current@FreeBSD.org> Subject: RE: KSE M-III status & junior hacker project. Message-ID: <Pine.BSF.4.21.0207091128210.35930-100000@InterJet.elischer.org> In-Reply-To: <Pine.NEB.3.96L.1020709141140.58636B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Jul 2002, Robert Watson wrote: > > On Tue, 9 Jul 2002, John Baldwin wrote: > > > > If anyone knows of something that was broken by the KSE commit, > > > (i.e. it worked just before and not after) and is STILL > > > broken please let me know because I think I can pretty much declare that > > > chapter finished, and I'd like to get on with "extending" KSE > > > functionality. This will be the start of Milestone IV, which would be > > > add support for threads to run on multiple processors. > > > Coincident with that some work should also proceed on gradually > > > identifying and cleaning up places in the kernel where multithreading > > > is just not ready.. e.g. which thread status do you get when you type ^T? > > > > I would like it if you would make KSE-3 work on other architectures now > > rather than adding more functionality that only works on i386. This > > would serve to validate the design decisions made thus far before a > > whole lot of code depends on those design decisions making it easier to > > make changes if need be. > > I have to admit I got a bit nervous about the KSE work on learning that > the existing fork-like approach was not compatible with several of our new > (or existing) target architectures; my impression was Julian and Doug had > hashed out a good solution to the problem at the dev summit last month, > however. I agree that getting at least one non-i386 platform working at > this point is really an important priority, since we really don't want to > bump into any more such problems. Also, since we're now getting to the > point where userland work is feasible, I think it's important that we > start to congeal a bit more on the multi-platform aware interface to avoid > building in assumptions that will be broken later resulting in a lot more > work. The reason that I couldn't commit it immediatly was that I had to rewrite some small parts to fit the new design that came from those discussions. As for userland.. that's basically a question for Dan. Chris Provenso who wrote the original MIT threads package indicated an interest in also taking part. > > Julian--following your conversation/design session with Doug, how long do > you think it would take to get i386 moved over to the revised design, and > then assuming you and someone infinitely familiar with the target platform > sat down together, how long would it take to bootstrap at least one more > platform to work with KSE? I tend to agree with John that this is an > important thing to have happen before we get too much more featureful. To > make an additional platform happen (say, Alpha or Sparc64), what would it > take in terms of expertise you don't have -- just someone familiar with > the architecture's context management and kernel trap code? I.e., a day > or two of Doug's, Jake's, or Peter's time? I386 is already running on the revised design. (though there is some cleanup that could be done) To get this running on another architecture, it takes the MD parts of the 386 KSE code being rewritten to fit the other architectures. I think it would take a couple of hours for someone "infinitely familiar" with the target to write those parts.. there are a couple hundred lines of C at most that need to be written. Basically the MD code requires that someone writes three major functions: 1/ write a thread's state to a given location in user memory so that it can be restarted. 2/ create a new thread context ready for an upcall, so that the upcall will jump to a given function with a given argument on a given stack. 3/ In user land, a pair of functions (setcontext and getcontext) to save and load a thread userland context in a compatible form with that saved in (1). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" 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.21.0207091128210.35930-100000>