Date: Mon, 24 Dec 2001 21:15:39 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: current@freebsd.org Subject: Re: KSE changes available Message-ID: <Pine.NEB.3.96L.1011224211511.31342B-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0112211558190.53471-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
For those of us that live in P4-land already, it's just the head of the KSE branch? Also, for those that don't, this is also available via cvsup10. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Fri, 21 Dec 2001, Julian Elischer wrote: > The latest round of KSE changes are available from > > http://www.freebsd.org/~julian/thediff > > These changes represent a work in progress. > Basically the state is: > > GENERIC compiles > (I don't know yet if it runs but I doubt it.) > The following changes have been made: > The 'thread' structure is no longer a built-in part of the proc structure. > There is an infrastructure to independently crfeate and reap threads. > The infrastructure is used to create and destroy the 'usual' single thread > associated with each process. It should eventually be used to create more > threads per process.. > The 'state' variable associated with the process has been raped and > now each thread, and process and KSE has it's own state. > > This last part is the bit that is broken because a LOT of the kernel > doesn't expect the state of a thread to be spread across several > structures. > > For example: > switch (p->p_stat) { > case SRUN: > ... > case SSTOP: > .. > > has to be completely rewritten because > SRUN is a per-thread property > and is accessed as: > FOREACH_THREAD_IN_PROC(p, td) { > switch(td->td_state) { > case TDS_RUNNING: > case TDS_RUNQ: > case TDS_SLP: > ... > } > ... > } > > wheras STOP is still a per-process state. > > obviously any code that tries to assume the same scope for these tow > states will break violently in the new code. > > I have replaced some of the logic where there seems to be a simple answer, > but there are plenty of places where the answer is not clear. > > Such places include signal delivery, > selection of process (thread?) to deliver a signal to, > collection of scheduling statistics, > handling FORK run by one of several threads, > handling EXIT run by one of several threads, > handling when the user types ^Z and suspends the process. > > If anyone is feeling adventurous they can stat with the code that is there > and start fixing things :-) > send me patches but let me know ahead of time what you will be doing > so we don't duplicate, and so I can send you notes on where I'm going in > that part.. > > I'll be working on the scheduler for the next few days I think. > > Note: if ((p->p_flag & P_KSES) == 0) a process should act exactly as it > does now.. :-) > > REGARDS JULIAN > (bloody capslock key) > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > 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.NEB.3.96L.1011224211511.31342B-100000>