Re: kernel thread creation cleanup

On 4/6/11 3:21 AM, Kostik Belousov wrote:
> On Tue, Apr 05, 2011 at 06:16:01PM -0700, Julian Elischer wrote:
>> I was just looking in the thread creation code after most of a decade
>> NOT looking at it..
>> boy we really need to go through there with a broom.. the cobwebs are
>> getting thick.
>> Like we always call the code to put an upcall, even though we don't
>> have upcalls any more,
> cpu_set_upcall() probably could be renamed to cpu_init_thread(),
> and cpu_set_upcall_kse() is better named cpu_init_thread_for_user().

yeah, we should have changed the names when they got the new jobs.
(when KSE went away)
> IMO, rename would only add a code churn.
>> and we always create an trap frame on the stack even when we are
>> making kernel threads
>> that don't need it, actually, come to think of it DOES fork even need
>> it? (need to go look)
> Trap frame for the new thread that is going to usermode after fork is
> definitely needed. Having fork trampoline executed for all threads is
> good, because it provides a convenient single point which is passed by
> all new threads.

One thing the  current code does is puts a trap frame on hte stack, 
whether you will need it or not.
the result of that is that the trap frame is the next thing on the 
stack after fork_exit on the stack so that if you return
from fork_exit you hit the frame (which is not set up to work) if you 
are creating a new  kthread.
not that you SHOULD return of course...
anyhow it's a waste of 192 bytes of stack..

For normal fork/thread_create I guess the frame tries to return to 
userland, and is needed.

>> and we go through the fork trampoline even when we are doing kthread
>> creation and could just as well go
>> directly to the final function directly.  (All of the above on amd64)..
>> May be slighly different on other hardware, though much of it is
>> encoded in MI code so probably not.
>>
>>
>>
>> This came from looking to see if I could somehow munge the stack to
>> convince kgdb to damn well stop at
>> that point (still failed.  if anyone has ideas... :-)
> Was it for amd64 ? I think the issue with kgdb is lack of the proper
> dwarf annotations for trampoline.

It's possible some sort of anotation woudl stop the stack when
it saw that return address, but one would think there was some other 
way too..
it even carries on with a 0 %rbp which is bogus.