From:   Steve James <saj@riscokid.phx.mcd.mot.com>
Message-Id: <200101162052.NAA10597@riscokid.phx.mcd.mot.com>
Subject: Re: PPC port vs. kl_task.c:kl_kernelstack()
To:     tjm@sgi.com (Tom Morano)
Date:   Tue, 16 Jan 2001 13:52:05 -0700 (MST)
Cc:     yakker@alacritech.com (Matt D. Robinson), lkcd@oss.sgi.com,
        tjm@sgi.com (Tom Morano),
        saj@riscokid.phx.mcd.mot.com (Steve James)
In-Reply-To: <3A64A940.8BC9E7AB@sgi.com> from "Tom Morano" at Jan 16, 2001 12:04:16 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-lkcd@oss.sgi.com
Precedence: bulk

> Hi Steve,
> 
> "Matt D. Robinson" wrote:
> > 
> > Steve James wrote:
> > >
> > > However, we have a problem.
> > > libklib/kl_task.c:kl_kernelstack() is not architecture indepentdent.
> > > This is because the thread structure for the PPC is not the
> > > same as for the other three architectures.  In particular,
> > > there is no member named "esp0".  (They call that "ksp" on
> > > the PPC.)   There could be similar problems in other libklib
> > > code that I will uncover as I get the stack backtrace stuff
> > > working.
> > >
> > > What is your philosophy about how to handle de-genericizing
> > > things like this?  For example, one approach would be to
> > > move the entire kl_kernelstack function into one of the
> > > architecture-dependent files.  Or have kl_kernelstack
> > > call an architecture-dependent function to actually
> > > get the esp0/ksp.  Or have kl_task.c include an
> > > architecture specific ".h" which defines a macro, which,
> > > in the case of the PPC, would transform the "esp0" references
> > > to "ksp" references?
> 
> Generally speaking, we're trying to have as little architecture specific
> code as possible. At one time, the kl_kernelstack() function was in
> an arch specific file, but I moved it (I didn't realize that there was
> a conflict with the PPC). What I have done now is to move the guts of 
> the kl_kernelstack() call to a function called _kernelstack(), which 
> is located in the libklib/arch/<your_arch>/kl_kern.c file. You can pick 
> this change up from the LKCD source repository on SourceForge. If you 
> run across any other situations similar to this, you can put the arch
> specific code there as well. 

This works for me.

> BTW, we really should get you set up as one 
> of the LKCD developers, so that you can add your own changes (especially 
> the PPC stuff) to the LKCD project. Do you already have a SourceForge 
> login?  

No, but I will look into that.  I have a whole bunch of 
observations/issues, etc. that I would like to share with
the list before making certain changes that I have been
tempted to make.
thx/
Steve James
steve_james@mcd.mot.com

> 
> Thanks,
> 
> Tom
>