Re: [RFC v3 3/8] Add basic Linux kernel support

[John Baldwin <jhb@freebsd.org>]

On Friday, May 19, 2017 07:05:47 PM Andreas Arnez wrote:
> On Fri, May 19 2017, John Baldwin wrote:
> 
> > FreeBSD's kernel GDB bits (which I maintain) have a similar issue, though for
> > now we only export kernel threads as threads in GDB and don't support CPUs as
> > a GDB-visible thing.  In some ways the model I would personally like would be
> > to have conceptual "layers" that you can bounce up and down between kind of
> > like a stack, but in this case a stack of thread targets, so that I could do
> > a kind of 'thread_down' and now 'info threads' would only show me CPUs, allow
> > me to select CPUs, etc. but then have a 'thread_up' to pop back up to the
> > kernel thread layer.
> 
> Exactly!  Note that GDB already has a stack of "layers" -- the target
> stack.  Thus I'm considering commands like "target up/down" for this
> purpose.  Of course this requires per-target thread lists.

Yes, a target up/down might work.  Right now you can push/pop targets so in
theory you can do this today with "target push kthread" and then "target pop".
I hadn't played with this enough to know if that would be sufficient or not
or if we wanted the targets to be more persistent to avoid having to recreate
the thread list during each push.  One thing I wanted to look at in more
detail is how this interaction worked for the older M:N threading targets.
FreeBSD used to use M:N threading in userland but abandoned that a while ago.
The old thread target for that used libthread_db and you only had the one
thread list, never a way to pop back down to the LWP view.

> > The best model I can think of is that this is similar to M:N
> > user-thread implementations where you have user threads multiplexed
> > onto LWPs.  In such a world (which I'm not sure many OS's use these
> > days) it would also be nice to kind of bounce between the worlds.
> 
> M:N user-thread implementations have probably become more popular with
> Go.  In that scenario we have the following layers:
> 
> * Threads == Goroutines (user-thread implementation)
> * Threads == OS threads

Hmm.

> > (In fact, the model I have been toying with but have not yet
> > implemented for adapting FreeBSD's current kernel target support to
> > qemu or the GDB stub I'm hacking on for FreeBSD's native bhyve
> > hypervisor would be to treat vCPUs as LWPs so their ptid would have
> > lwp == vcpu, and kernel-level threads as "threads", so their ptid
> > would have tid == kernel thread id).
> 
> So kernel-level threads can not be rescheduled on a different vCPU?

They definitely can.  The same is true for user-level thread with LWPs
on systems with M:N threading (e.g. scheduler activations on Solaris
or FreeBSD's old KSE M:N threading model).

-- 
John Baldwin