public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lennart Poettering <mzxreary@0pointer.de>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Richard Weinberger <richard@nod.at>
Subject: Re: [PATCH] um: change defconfig to stop spawning xterm
Date: Tue, 23 Jul 2013 00:32:39 +0200	[thread overview]
Message-ID: <20130722223238.GC13191@tango.0pointer.de> (raw)
In-Reply-To: <CALkWK0mpH9XHL2PZK47Lb9frf9hFNQ8sjF2_0p7VJnY8XWhiGw@mail.gmail.com>

On Mon, 22.07.13 16:13, Ramkumar Ramachandra (artagnon@gmail.com) wrote:

> 
> [Corrected Lennart's email ID]
> 
> Richard Weinberger wrote:
> > CC'ing Lennart.
> >
> > Am 22.07.2013 11:45, schrieb Ramkumar Ramachandra:
> >> Ramkumar Ramachandra wrote:
> >>> [1]: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012152.html
> >>
> >> ... and the patches were rejected.  Lennart says that UML providing
> >> /dev/tty* is wrong, and that UML should call them /dev/hvc* (or
> >> something).  Can we do something about the situation?  Can we remove
> >> /dev/tty*, and provide /dev/hvc*?  Will we be breaking existing users?
> >>
> >> Thanks.
> >>
> >> Lennart Poettering wrote:
> >>> UML shouldn't be penalized for not implementing some terminal emulation,
> >>> but it should be penalized for doing so under the label of "VT support",
> >>> which it simply is not providing.
> >>>
> >>> They can call their ttys any way they want. If the call them
> >>> /dev/tty[1..64] however, then they need to implement the VC
> >>> interfaces. All of them.
> >
> > Lennart, can you please explain us why /dev/tty[1..64] is forced to
> > have virtual console support?

/dev/tty[1..64] is the userspace API to the kernel VT subsystem. If you
support it you need to match up all /dev/tty[1..64] with a
/dev/vcs[1..64] + /dev/vcsa[1..64]. You need to expose a tty that
understands TERM=linux and the ioctls listed on console_ioctl(4). You
need /dev/tty0 as something that behaves like a symlink to the fg
VT. You should also support files like /sys/class/tty/tty0/active with
its POLLHUP iface.

If you expose a very different terminal than a VT as /dev/tty[1..64]
this will confuse a lot of userspace, since userspace, be it
systemd/logind, gpm, X11, openvt, ... all expect that /dev/tty[1..64] is
the VT subsystem where all that functionality is available. And you just
broke the userspace API quite badly.

It's totally fine to register ttys with a different feature set under
some other name you like, but if you name it /dev/tty[1..64] then
userspace expects this to be the real deal.

The various hypervisors understood this and provide their ttys under the
name of /dev/hvc0 and suchlike. UML should probably do something
similar. If you pick a name of your own, you have complete freedom what
you actually implement...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

  parent reply	other threads:[~2013-07-22 22:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-19 18:20 [PATCH] um: change defconfig to stop spawning xterm Ramkumar Ramachandra
2013-07-19 18:44 ` Richard Weinberger
2013-07-19 19:44   ` Ramkumar Ramachandra
2013-07-22  9:45     ` Ramkumar Ramachandra
2013-07-22 10:38       ` Richard Weinberger
2013-07-22 10:43         ` Ramkumar Ramachandra
2013-07-22 11:48           ` Ramkumar Ramachandra
2013-07-22 22:32           ` Lennart Poettering [this message]
2013-07-23  5:40             ` Richard Weinberger
2013-07-23  5:47               ` richard -rw- weinberger
2013-07-23  7:57                 ` Al Viro
2013-07-24 16:49                   ` Lennart Poettering
2013-07-24 16:38               ` Lennart Poettering
2013-07-22 12:40       ` Al Viro
2013-07-22 13:02         ` Ramkumar Ramachandra
2013-07-22 13:20           ` Richard Weinberger
2013-07-22 13:42             ` Ramkumar Ramachandra
2013-07-22 14:08               ` Richard Weinberger
2013-07-22 15:33                 ` Ramkumar Ramachandra
2013-07-22 19:29                   ` Richard Weinberger
2013-07-22 20:01                     ` Ramkumar Ramachandra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130722223238.GC13191@tango.0pointer.de \
    --to=mzxreary@0pointer.de \
    --cc=artagnon@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox