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

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

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.

> 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

> (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?

--
Andreas