>> One thing window can't do is let you run two X sessions on different
>> virtual terminals [...].
> BTW, this is *exactly* the sort of thing that would be much better
> done in user-land.  [...]

I'm not sure whether I agree or not.  Back in R4 days, I took the Sun
bwtwo server, hijacked a couple of keys, and implemented multiple
sessions (multiple instances of the server) on a single display, by
switching displays which didn't have the hardware to using a memory
area instead of the framebuffer.  Worked fine.

But there's more to this.  Some reasons come to mind why such a tactic
would not be a complete substitute for virtual consoles.

- The multi-session server allows switching only between X sessions; it
  has no support for text sessions.  (In our situation, this runs on
  our X terminal Suns, so this is not a problem.)

- All servers run under the same uid.  If you always run X and use xdm,
  as we do on the machines in question, this is not a problem - but it
  is in any situation where users more commonly use xinit.

- If one server locks up, at least with the scheme I implemented, you
  can't switch to another session, because the switching was done by
  having the relinquishing server actively give up the hardware.

The third of these is definitely fixable.  The other two may be, but it
would be a good deal more work.  In my opinion, kernel-resident virtual
session switching is not an inappropriate way to resolve the problem.
It has problems, yes, but so does any other solution.  And provided the
support can easily be compiled out, it imposes no penalty on those who
prefer user-land solutions; the only penalty incurred is some extra
maintenance work and any hooks required into the rest of the kernel.  I
haven't read the x86 virtual console code, and don't know enough about
the hardware to know what's involved - but the equivalent code on the
SPARC or Sun-3 would be small enough and well-isolated enough that I
wouldn't hesitate to leave it in the kernel.  And to some extent, more
complicated hardware would be an argument _for_ putting it in the
kernel, because it means only one piece of code has to know all the
things which need to be swapped in and out when switching.  Besides,
you need _some_ kernel support anyway, unless you propose to let the
user-land processes at the raw hardware.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu