From owner-freebsd-current Mon Dec 24 18:15:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EE8EB37B417 for ; Mon, 24 Dec 2001 18:15:54 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBP2FdD33400; Mon, 24 Dec 2001 21:15:39 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 24 Dec 2001 21:15:39 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: current@freebsd.org Subject: Re: KSE changes available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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