[RFC][PATCH] discontiguous vterms

[Hollis Blanchard]

[resend; had some bounces the first time]

On Sunday, Nov 2, 2003, at 23:19 US/Central, Paul Mackerras wrote:
>
> Any chance of these things appearing and disappearing at runtime?

It's ambiguous. There are a few factors:

 From my reading of the Logical Resource Dynamic Reconfiguration
documentation, it's possible.

Currently the Linux's vterms always "hosted by" the hypervisor. In the
future this is not necessarily true -- you can have one LPAR hosting
the consoles of others. (This is called "vty-server".)

It may not make much sense to dynamically add another console session
to the hypervisor/HMC. However, once that vty-server functionality is
in place, it may make sense to dynamically add vty-server consoles
(e.g. you have one console LPAR and as you boot more LPARs you want to
add more vterm sessions to the console LPAR).

However, the vty-server description seems to have something else in
mind: it describes a system in which you have N console sessions at
boot, and at runtime you instruct the hypervisor to connect those
sessions to different clients, as long as you were only talking to N at
a time. Perhaps this is intended to avoid having the dynamically add
dozens of consoles for dozens of LPARs.

In conclusion, I have no idea. But if DR vterms is done, I don't expect
that functionality to show up for a while (for whatever that's worth ;)

> Perhaps we should have the arch code calling some hvc_console routine
> to tell it about consoles, rather than having hvc_console calling arch
> code to discover the consoles as at present.  The only thing is that
> getting the `add_console' routine called at the right time in the boot
> sequence might be interesting.

Yup, that's just like the (hotpluggable) PCI driver model which
presents a table of interesting devices and then has a "probe" function
called when such devices show up.

To make the driver properly support removable consoles (via that
hotplug mechanism) would take significantly more work. I started going
down that path, but the diff to the driver became large, and since all
that code would go unused right now (and maybe forever) I couldn't
justify it...

--
Hollis Blanchard
IBM Linux Technology Center


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/