Non X console removal

Adam Jackson ajax at redhat.com
Mon Sep 15 17:15:37 UTC 2008


On Mon, 2008-09-15 at 11:56 -0400, Alan Cox wrote:

> Now as the API - it has interesting design features that go back ten years to
> a different model of usage. Right now that code is all getting revamped, fine
> grain locked and tidied so now is a very good time for the distro folks to
> produce and send out a "What we hate about the console and how we think it
> could be addressed" email...

You fundamentally can not do VT switch reliably with the current
VT_ACTIVATE / VT_WAITACTIVE pair.  If someone sneaks in with an ACTIVATE
between your two ioctls, you'll hang forever.  You can't even fix all
the userspace callers to do "something reliable" to work around it.

I don't see how we can have a reliable vt subsystem while still claiming
those ioctls work.  But Linus isn't about to let us break them, so, sort
of an impasse here.

I think what we want is:

- command to say "activate this VT or die trying".  I'm not sure how to
have this without breaking the idea of "process mode" altogether.
- file descriptor that selects readable when a vt change happens, for
ConsoleKit and friends.

Initially I also thought we'd want a third feature here for "let me
finalize switches", but I think this is unnecessary, userspace
synchronization will work fine.

We also (need, want) a kernel concept of a seat that binds together
displays and input devices.  Right now, multiseat requires that you
abandon vt switching as a feature; if you're not careful about seat
setup right now, c-a-f1 on one person's seat will stop X on the other
seats.  It's fine if "seat zero" is the legacy seat and some system
policy service handles setting up /dev/seat1/vt*.

Then we need some way of very early in life switching to the new sane
model and never letting go.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20080915/c8949d3d/attachment.sig>


More information about the fedora-test-list mailing list