Differences between revisions 1 and 2
Revision 1 as of 2007-05-16 16:32:16
Size: 790
Editor: scott
Comment: device-based gettys
Revision 2 as of 2007-05-16 16:35:02
Size: 1034
Editor: scott
Comment:
Deletions are marked like this. Additions are marked like this.
Line 18: Line 18:

 * This will almost certainly need to be combined with some other events or state, for example when there is a writable filesystem. These need to not mask out the tty events, which are the "prime" ones as far as this instance is concerned.

Device-based gettys

Johan pointed out that the current one-file-per-getty configuration isn't very flexible, not to mention not very Upstartish; and there's a much better solution. Have a single getty job that spawns an instance for each terminal configured.

  • Spawn instance, and set goal to start, on the tty-added event; optionally matching the name of the tty to limit, e.g.

    tty-added tty[1-6]
  • Set goal to stop on the tty-removed event; matching the first argument from the start event, e.g.

    tty-removed $1
  • Instance can be destroyed once stopped; though this might not be desirable, since we might want to be able to start it again.
  • We'll need to keep the emission record for the start event as long as the instance is active.
  • This will almost certainly need to be combined with some other events or state, for example when there is a writable filesystem. These need to not mask out the tty events, which are the "prime" ones as far as this instance is concerned.

ComplexEventConfig/StrawMen (last edited 2007-05-16 16:35:02 by scott)