[PATCH] um: change defconfig to stop spawning xterm

[PATCH] um: change defconfig to stop spawning xterm

[Ramkumar Ramachandra]

The default configuration dictates that um Linux will launch xterms
connected to various tty devices on the host.  It makes more sense to
connect to /dev/pts/N, so that the host can:

  $ screen /dev/pts/N

or

  $ minicom /dev/pts/N

to start talking to the guest session.  Note that
con0 (CONFIG_CON_ZERO_CHAN) still defaults to "fd:0,fd:1", printing boot
messages on the same terminal.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Richard Weinberger <richard@nod.at>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 Further, I will patch systemd to getty on con0 when um Linux is
 detected.  Thanks for all the help, and sorry I took so long to
 figure it out.

 Applies on top of the patch I sent earlier.

 arch/um/configs/i386_defconfig   | 2 +-
 arch/um/configs/x86_64_defconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/um/configs/i386_defconfig b/arch/um/configs/i386_defconfig
index 995aecd..74d8823 100644
--- a/arch/um/configs/i386_defconfig
+++ b/arch/um/configs/i386_defconfig
@@ -278,7 +278,7 @@ CONFIG_TTY_CHAN=y
 CONFIG_XTERM_CHAN=y
 # CONFIG_NOCONFIG_CHAN is not set
 CONFIG_CON_ZERO_CHAN="fd:0,fd:1"
-CONFIG_CON_CHAN="xterm"
+CONFIG_CON_CHAN="pts"
 CONFIG_SSL_CHAN="pts"
 CONFIG_UML_SOUND=m
 CONFIG_SOUND=m
diff --git a/arch/um/configs/x86_64_defconfig b/arch/um/configs/x86_64_defconfig
index f2c6123..7d4cbbf 100644
--- a/arch/um/configs/x86_64_defconfig
+++ b/arch/um/configs/x86_64_defconfig
@@ -270,7 +270,7 @@ CONFIG_TTY_CHAN=y
 CONFIG_XTERM_CHAN=y
 # CONFIG_NOCONFIG_CHAN is not set
 CONFIG_CON_ZERO_CHAN="fd:0,fd:1"
-CONFIG_CON_CHAN="xterm"
+CONFIG_CON_CHAN="pts"
 CONFIG_SSL_CHAN="pts"
 CONFIG_UML_SOUND=m
 CONFIG_SOUND=m
-- 
1.8.3.3.797.gb72c616.dirty

Re: [PATCH] um: change defconfig to stop spawning xterm

[Richard Weinberger]

Am 19.07.2013 20:20, schrieb Ramkumar Ramachandra:
> The default configuration dictates that um Linux will launch xterms
> connected to various tty devices on the host.  It makes more sense to
> connect to /dev/pts/N, so that the host can:
> 
>   $ screen /dev/pts/N
> 
> or
> 
>   $ minicom /dev/pts/N
> 
> to start talking to the guest session.  Note that
> con0 (CONFIG_CON_ZERO_CHAN) still defaults to "fd:0,fd:1", printing boot
> messages on the same terminal.

Makes sense. Queued for 3.12.

Thanks,
//richard

> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Richard Weinberger <richard@nod.at>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
>  Further, I will patch systemd to getty on con0 when um Linux is
>  detected.  Thanks for all the help, and sorry I took so long to
>  figure it out.
> 
>  Applies on top of the patch I sent earlier.
> 
>  arch/um/configs/i386_defconfig   | 2 +-
>  arch/um/configs/x86_64_defconfig | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/um/configs/i386_defconfig b/arch/um/configs/i386_defconfig
> index 995aecd..74d8823 100644
> --- a/arch/um/configs/i386_defconfig
> +++ b/arch/um/configs/i386_defconfig
> @@ -278,7 +278,7 @@ CONFIG_TTY_CHAN=y
>  CONFIG_XTERM_CHAN=y
>  # CONFIG_NOCONFIG_CHAN is not set
>  CONFIG_CON_ZERO_CHAN="fd:0,fd:1"
> -CONFIG_CON_CHAN="xterm"
> +CONFIG_CON_CHAN="pts"
>  CONFIG_SSL_CHAN="pts"
>  CONFIG_UML_SOUND=m
>  CONFIG_SOUND=m
> diff --git a/arch/um/configs/x86_64_defconfig b/arch/um/configs/x86_64_defconfig
> index f2c6123..7d4cbbf 100644
> --- a/arch/um/configs/x86_64_defconfig
> +++ b/arch/um/configs/x86_64_defconfig
> @@ -270,7 +270,7 @@ CONFIG_TTY_CHAN=y
>  CONFIG_XTERM_CHAN=y
>  # CONFIG_NOCONFIG_CHAN is not set
>  CONFIG_CON_ZERO_CHAN="fd:0,fd:1"
> -CONFIG_CON_CHAN="xterm"
> +CONFIG_CON_CHAN="pts"
>  CONFIG_SSL_CHAN="pts"
>  CONFIG_UML_SOUND=m
>  CONFIG_SOUND=m
> 

Re: [PATCH] um: change defconfig to stop spawning xterm

[Ramkumar Ramachandra]

With these finishing touches [1], um Linux should work right out of
the box on modern distributions.

Thanks.

[1]: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012152.html

Re: [PATCH] um: change defconfig to stop spawning xterm

[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.
>
> Also note that some hypervisors implement /dev/hvc0, /dev/xvc0,
> /dev/hvsi0 and suchlike. Theser are also ttys, which are used for
> interfacing in a VT-like way the virtual machines. But they do not claim
> to ve the real VT, they hence picked different tty names.
>
> UML should follow the same route: pick some name you like, or even
> better, pick one of the existing hypervisor tty names if the interface
> and usecase is the same, but do not use /dev/tty[1..64], because that is
> the VT subsystem.
>
> systemd handles the hvc0, xvc0, hvsi0 automatically already. We'd be
> happy if UML could make use of the same logic.

Re: [PATCH] um: change defconfig to stop spawning xterm

[Richard Weinberger]

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?

Thanks,
//richard

Re: [PATCH] um: change defconfig to stop spawning xterm

[Ramkumar Ramachandra]

[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?
>
> Thanks,
> //richard

Re: [PATCH] um: change defconfig to stop spawning xterm

[Ramkumar Ramachandra]

> Richard Weinberger wrote:
>> Lennart, can you please explain us why /dev/tty[1..64] is forced to
>> have virtual console support?

The crux of Lennart's argument seems to be that several applications
depend on it, and that applications have to bend over backwards when
those expectations are broken [1].  He has also pointed out that
hypervisor applications implement /dev/hvc0, /dev/xvc0, and /dev/hvsi0
by convention (which serve the same purpose), and that systemd
supports them.  I'm not going to argue about hard rules, because it's
clearly possible to enable CONFIG_TTY and disable CONFIG_VT in the tty
driver (the Kconfig allows this), as um Linux has done.

Since um Linux behaves more like a "container" application, is it
feasible to replace the /dev/tty* with /dev/hvc* in a
backward-compatible manner?  I think it is, although I may be missing
something: we just have to deprecate "tty" in the command-line options
to actually point to /dev/hvc*, and enable HVC_DRIVER/HVC_CONSOLE,
right?  It should be fairly straightforward to deprecate drivers/tty.c
in favor of a newer drivers/hvc.c, I think.

Let me know if I've said something stupid, so I can stop writing the patches.

Thanks.

[1]: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012212.html

Re: [PATCH] um: change defconfig to stop spawning xterm

[Al Viro]

On Mon, Jul 22, 2013 at 03:15:14PM +0530, Ramkumar Ramachandra wrote:
> 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?

Yes, you would be breaking existing users.  Starting with anybody with static
/dev.  Or a debian userland, for that matter.  Any systemd-free setup,
actually.

Changing device number assignments is not to be done lightly, whether
they should've been set that way back then or not.

As for Lennart's opinion...  *shrug*  He's free to do whatever he wants
in systemd.  It does not translate into having any kind of control over
the kernel.

Re: [PATCH] um: change defconfig to stop spawning xterm

[Ramkumar Ramachandra]

Al Viro wrote:
> On Mon, Jul 22, 2013 at 03:15:14PM +0530, Ramkumar Ramachandra wrote:
>> 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?
>
> Yes, you would be breaking existing users.  Starting with anybody with static
> /dev.  Or a debian userland, for that matter.  Any systemd-free setup,
> actually.

Systemd does not support a static /dev, so we're talking about
non-systemd systems.  Ofcourse I reject anything that breaks existing
users.

> Changing device number assignments is not to be done lightly, whether
> they should've been set that way back then or not.

I never proposed something as ridiculous as changing device number
assignments.  I'm trying to add a HVC_DRIVER to um Linux: I enabled it
in the Kconfig; any idea how to get devtmpfs to populate /dev with
hvc* device nodes now?

> As for Lennart's opinion...  *shrug*  He's free to do whatever he wants
> in systemd.  It does not translate into having any kind of control over
> the kernel.

If you care about users, you will stop worrying about different
people's "opinions", "control", and work towards a solution.  I want
great user-experience, period.  You can continue to argue endlessly
about the sanity of Lennart/systemd for all I care, but you cannot
deny the fact that systemd has _users_.  Users that you must support.

So, what should we do?

Re: [PATCH] um: change defconfig to stop spawning xterm

[Richard Weinberger]

Am 22.07.2013 15:02, schrieb Ramkumar Ramachandra:
> If you care about users, you will stop worrying about different
> people's "opinions", "control", and work towards a solution.  I want
> great user-experience, period.  You can continue to argue endlessly
> about the sanity of Lennart/systemd for all I care, but you cannot
> deny the fact that systemd has _users_.  Users that you must support.

Can we please keep it on a technical level?
"great user-experience" and other marketing buzzwords belong to Ubuntu land.

> So, what should we do?

What technical problem are you facing?
I'm using systemd distros all day on top of UML.

Thanks,
//richard

Re: [PATCH] um: change defconfig to stop spawning xterm

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> "great user-experience" and other marketing buzzwords belong to Ubuntu land.

Ubuntu uses upstart; I have no idea why you brought it up.

> What technical problem are you facing?
> I'm using systemd distros all day on top of UML.

I started the thread with two patches [1][2].  Do the patches _not_
address problems?  Are the problems invalid in some way?  Are the
commit messages unclear?

[1]: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012153.html
[2]: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012154.html

Re: [PATCH] um: change defconfig to stop spawning xterm

[Richard Weinberger]

Am 22.07.2013 15:42, schrieb Ramkumar Ramachandra:
> Richard Weinberger wrote:
>> "great user-experience" and other marketing buzzwords belong to Ubuntu land.
> 
> Ubuntu uses upstart; I have no idea why you brought it up.
> 
>> What technical problem are you facing?
>> I'm using systemd distros all day on top of UML.
> 
> I started the thread with two patches [1][2].  Do the patches _not_
> address problems?  Are the problems invalid in some way?  Are the
> commit messages unclear?
> 
> [1]: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012153.html
> [2]: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012154.html

Again what problem are you trying to solve?
If you want a getty on /dev/tty0, run:

ln -s /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty0.service

Thanks,
//richard

Re: [PATCH] um: change defconfig to stop spawning xterm

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> Again what problem are you trying to solve?
> If you want a getty on /dev/tty0, run:

To get systemd to do that for me automatically :)

It automatically does the right thing when it detects xen, bochs,
qemu, vmware, microsoft, oracle, chroot, openvz, and lxc.  So, why not
uml?

[1/2] is about getting it to active console-getty.service when uml is detected.

[2/2] is about getting it to disable vconsole-setup.service when uml
is detected (since it uml doesn't do VT emulation, and the service
will always fail).

Too minor a problem?

Re: [PATCH] um: change defconfig to stop spawning xterm

[Richard Weinberger]

Am 22.07.2013 17:33, schrieb Ramkumar Ramachandra:
> Richard Weinberger wrote:
>> Again what problem are you trying to solve?
>> If you want a getty on /dev/tty0, run:
> 
> To get systemd to do that for me automatically :)
> 
> It automatically does the right thing when it detects xen, bochs,
> qemu, vmware, microsoft, oracle, chroot, openvz, and lxc.  So, why not
> uml?

Ask systemd folks. UML exists much longer than systemd.

> [1/2] is about getting it to active console-getty.service when uml is detected.
> 
> [2/2] is about getting it to disable vconsole-setup.service when uml
> is detected (since it uml doesn't do VT emulation, and the service
> will always fail).
> 
> Too minor a problem?

No, but we won't break existing applications, period.
If you offer me a solution that does not break any existing applications
and solves your systemd issue we can talk. :-)

Thanks,
//richard

Re: [PATCH] um: change defconfig to stop spawning xterm

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> No, but we won't break existing applications, period.

We're on the same page: I'm absolutely against breaking existing users too.

> If you offer me a solution that does not break any existing applications
> and solves your systemd issue we can talk. :-)

I think a hv console driver for um Linux will solve the problem, but I
can't be sure.  I'm trying to write one, and I'll hopefully have
something to show in a few more caffeinated hours.

Let me know if you have any thoughts/ pointers.

Re: [PATCH] um: change defconfig to stop spawning xterm

[Lennart Poettering]

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.

Re: [PATCH] um: change defconfig to stop spawning xterm

[Richard Weinberger]

Lennart,

Am 23.07.2013 00:32, schrieb Lennart Poettering:
> 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.

I sightly disagree with you.
/dev/tty[1..64] is not directly bound to VT.
You can have systems with CONFIG_VT=n and still have /dev/tty[1..64].
Linux supports this perfectly.
UML does not have VT because having virtual consoles makes no sense.
(Same like on s390)

Thanks,
//richard

Re: [PATCH] um: change defconfig to stop spawning xterm

[richard -rw- weinberger]

Adding Al again, someone dropped him from the CC list...

On Tue, Jul 23, 2013 at 7:40 AM, Richard Weinberger <richard@nod.at> wrote:
> Lennart,
>
> Am 23.07.2013 00:32, schrieb Lennart Poettering:
>> 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.
>
> I sightly disagree with you.
> /dev/tty[1..64] is not directly bound to VT.
> You can have systems with CONFIG_VT=n and still have /dev/tty[1..64].
> Linux supports this perfectly.
> UML does not have VT because having virtual consoles makes no sense.
> (Same like on s390)
>
> Thanks,
> //richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



--
Thanks,
//richard

Re: [PATCH] um: change defconfig to stop spawning xterm

[Al Viro]

On Tue, Jul 23, 2013 at 07:47:07AM +0200, richard -rw- weinberger wrote:
> Adding Al again, someone dropped him from the CC list...

FWIW, all this crap stems from the old decision to use major 4 for
uml consoles.  And it was a bad decision, no arguments here.
It's also a decision we are years too late to revert.

a) VT102, let alone the extensions to it, is simply wrong for uml;
if it's understood by anything, it's on the host userland side.
xterm(1) has a notion of two-dimensional array of characters on screen,
organized in logical lines, etc.  So does screen(1).  So does
drivers/tty/vt/* (i.e. the kernel side of virtual console).  uml
console does *not* have such a notion - it passes a linear stream
of octets, sight unseen, to whatever's on the other side of connection.
Doing an equivalent of drivers/tty/vt/* would mean maintaining such
a 2D array internally *AND* somehow passing updates to that beast
to whatever's on the other side.  That could be done (after all,
libcurses manages), but it won't be compatible with existing setups
and it should be a separate driver, anyway.  Granted, it would've
made a whole lot more sense in role of /dev/tty<n>, but it's too late
for that now.

b) changing the major of /dev/tty<n> on uml will break existing setups.
Ain't feasible.  We probably can get away with making that controlled
by kernel option, and it might make sense to try going that way, but
I'm not entirely convinced it's worth bothering.  Up to uml maintainer...
IMO if we go that way, we ought to pass the relevant part of config
(i.e. is it xterm or pts or plain opened file) in the event udev
gets, so that the userland would have at least a chance of dealing
with another real problem - selecting TERM value for getty.

Re: [PATCH] um: change defconfig to stop spawning xterm

[Lennart Poettering]

On Tue, 23.07.13 07:40, Richard Weinberger (richard@nod.at) 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.
> 
> I sightly disagree with you.
> /dev/tty[1..64] is not directly bound to VT.
> You can have systems with CONFIG_VT=n and still have /dev/tty[1..64].
> Linux supports this perfectly.
> UML does not have VT because having virtual consoles makes no sense.
> (Same like on s390)

You are aware that turning off the tty subsystem in the kernel is
something different than turning off the virtual console? Note that the
whole stuff is really confusingly named, as /dev/tty1 is genericly named
"tty", even if it actually refers to a virtual console tty and nothing else.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: [PATCH] um: change defconfig to stop spawning xterm

[Lennart Poettering]

On Tue, 23.07.13 08:57, Al Viro (viro@ZenIV.linux.org.uk) wrote:

> 
> On Tue, Jul 23, 2013 at 07:47:07AM +0200, richard -rw- weinberger wrote:
> > Adding Al again, someone dropped him from the CC list...
> 
> FWIW, all this crap stems from the old decision to use major 4 for
> uml consoles.  And it was a bad decision, no arguments here.
> It's also a decision we are years too late to revert.
> 
> a) VT102, let alone the extensions to it, is simply wrong for uml;
> if it's understood by anything, it's on the host userland side.
> xterm(1) has a notion of two-dimensional array of characters on screen,
> organized in logical lines, etc.  So does screen(1).  So does
> drivers/tty/vt/* (i.e. the kernel side of virtual console).  uml
> console does *not* have such a notion - it passes a linear stream
> of octets, sight unseen, to whatever's on the other side of connection.
> Doing an equivalent of drivers/tty/vt/* would mean maintaining such
> a 2D array internally *AND* somehow passing updates to that beast
> to whatever's on the other side.  That could be done (after all,
> libcurses manages), but it won't be compatible with existing setups
> and it should be a separate driver, anyway.  Granted, it would've
> made a whole lot more sense in role of /dev/tty<n>, but it's too late
> for that now.

The UML tty devices are in most regards pretty much like serial TTYs
where there's also no meta-information available which terminal
emulation is actually spoken on it, and that's covered pretty much OK
everyhwere...

> b) changing the major of /dev/tty<n> on uml will break existing setups.
> Ain't feasible.  We probably can get away with making that controlled
> by kernel option, and it might make sense to try going that way, but
> I'm not entirely convinced it's worth bothering.  Up to uml maintainer...
> IMO if we go that way, we ought to pass the relevant part of config
> (i.e. is it xterm or pts or plain opened file) in the event udev
> gets, so that the userland would have at least a chance of dealing
> with another real problem - selecting TERM value for getty.

Which major/minor you use is irrelevant to userspace. The userspace API
however assumes that /dev/tty[1..63] refers to the tty devices of the
virtual console. As long as you provide some other TTY under that name
then the virtual console TTYs you simply provide a broken API to
userspace, and hence programs break. systemd does, gpm does, X11 does,
and everything else that interfaces with the VC via VC APIs does too.

Just pick a different name for the TTYs that UML uses, just not
/dev/tty[1..63] and everything is fine. That's what the virtualization
folks did with their hypervisor consoles, and is what we required from
the container folks too.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.