On Mon, 24 Dec 2001, Glenn Gombert wrote:
>
> In case anyone is interested I have put a set of patched source code
> files from the link below on my FreeBSD Web Page at:
>
> freebsd.imatowns.com/kse3
>
> There are the patched source code files,individual patches (from the
> link below) and the un-patched source files in three differnet directories:
>
> /patched-src
> /patches
> /unpatched-src
>
> I have not tried to compile these yet, I just finished getting the source
> files patched :)
As someone mentionned, the up-to-date KSE tree is available
through cvsup10 but I don't know the collection.
maybe peter can remind us how to get it.
Julian
p.s. I'm quite close to needing those syscall stubs :-) (a few days)
>
> Glenn G.
>
>
> ---- Julian Elischer <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> >
>
> __________________________________________________
> FREE voicemail, email, and fax...all in one place.
> Sign Up Now! http://www.onebox.com
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
