lkcd
[Top] [All Lists]

Re: PPC port vs. kl_task.c:kl_kernelstack()

To: Steve James <saj@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: PPC port vs. kl_task.c:kl_kernelstack()
From: "Matt D. Robinson" <yakker@xxxxxxxxxxxxxx>
Date: Tue, 16 Jan 2001 10:35:19 -0800
Cc: Tom Morano <tjm@xxxxxxx>, lkcd@xxxxxxxxxxx, steve_james@xxxxxxxxxxxxxxxxxxxxxxxx
Organization: Alacritech, Inc.
References: <200101161825.LAA10256@riscokid.phx.mcd.mot.com>
Sender: owner-lkcd@xxxxxxxxxxx
Steve James wrote:
> 
> > And thanks for doing work on a PowerPC port. From an lcrash point of
> > view, you can do a lot of work without actually having LKCD kernel
> > functionality in place. As long as you have a "namelist" file you
> > can start up lcrash on a live system. You need to make sure that
> > you run the configure script in lkcdutils with the --topdir flag
> > set to your kernel source tree (if it's not /usr/src/linux). You will
> > then be able to do a 'make namelist' from within the libklib directory.
> > Use the resulting namelist in the following manner:
> >
> > # lcrash /boot/System.map /dev/mem namelist
> >
> > You will then be able to work on the architecture specific stuff like
> > stack traces for running tasks. Or, you may already be beyond this point.
> 
> Yes, my porting effort is well beyond that point.  A great many
> things are working.  It is easy when you start with good code :)
> 
> 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?

I'd assume the second answer, but I'll let Tom answer
definitively since that's his ball of wax.

--Matt

> If you can't get ahold of the PPC ".h" files for the
> thread structure, etc., let me know and I'll mail 'em
> out.

<Prev in Thread] Current Thread [Next in Thread>