* [PATCH] um: change defconfig to stop spawning xterm @ 2013-07-19 18:20 Ramkumar Ramachandra 2013-07-19 18:44 ` Richard Weinberger 0 siblings, 1 reply; 21+ messages in thread From: Ramkumar Ramachandra @ 2013-07-19 18:20 UTC (permalink / raw) To: LKML; +Cc: Al Viro, Richard Weinberger 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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 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 0 siblings, 1 reply; 21+ messages in thread From: Richard Weinberger @ 2013-07-19 18:44 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: LKML, Al Viro 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 > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-19 18:44 ` Richard Weinberger @ 2013-07-19 19:44 ` Ramkumar Ramachandra 2013-07-22 9:45 ` Ramkumar Ramachandra 0 siblings, 1 reply; 21+ messages in thread From: Ramkumar Ramachandra @ 2013-07-19 19:44 UTC (permalink / raw) To: Richard Weinberger; +Cc: LKML, Al Viro 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-19 19:44 ` Ramkumar Ramachandra @ 2013-07-22 9:45 ` Ramkumar Ramachandra 2013-07-22 10:38 ` Richard Weinberger 2013-07-22 12:40 ` Al Viro 0 siblings, 2 replies; 21+ messages in thread From: Ramkumar Ramachandra @ 2013-07-22 9:45 UTC (permalink / raw) To: Al Viro; +Cc: LKML, Richard Weinberger 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 9:45 ` Ramkumar Ramachandra @ 2013-07-22 10:38 ` Richard Weinberger 2013-07-22 10:43 ` Ramkumar Ramachandra 2013-07-22 12:40 ` Al Viro 1 sibling, 1 reply; 21+ messages in thread From: Richard Weinberger @ 2013-07-22 10:38 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Al Viro, LKML, lpoetter 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 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 0 siblings, 2 replies; 21+ messages in thread From: Ramkumar Ramachandra @ 2013-07-22 10:43 UTC (permalink / raw) To: Lennart Poettering; +Cc: Al Viro, LKML, Richard Weinberger [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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 10:43 ` Ramkumar Ramachandra @ 2013-07-22 11:48 ` Ramkumar Ramachandra 2013-07-22 22:32 ` Lennart Poettering 1 sibling, 0 replies; 21+ messages in thread From: Ramkumar Ramachandra @ 2013-07-22 11:48 UTC (permalink / raw) To: Richard Weinberger; +Cc: Al Viro, LKML, Lennart Poettering > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 10:43 ` Ramkumar Ramachandra 2013-07-22 11:48 ` Ramkumar Ramachandra @ 2013-07-22 22:32 ` Lennart Poettering 2013-07-23 5:40 ` Richard Weinberger 1 sibling, 1 reply; 21+ messages in thread From: Lennart Poettering @ 2013-07-22 22:32 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: LKML, Richard Weinberger 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 22:32 ` Lennart Poettering @ 2013-07-23 5:40 ` Richard Weinberger 2013-07-23 5:47 ` richard -rw- weinberger 2013-07-24 16:38 ` Lennart Poettering 0 siblings, 2 replies; 21+ messages in thread From: Richard Weinberger @ 2013-07-23 5:40 UTC (permalink / raw) To: Lennart Poettering; +Cc: Ramkumar Ramachandra, LKML 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 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:38 ` Lennart Poettering 1 sibling, 1 reply; 21+ messages in thread From: richard -rw- weinberger @ 2013-07-23 5:47 UTC (permalink / raw) To: Richard Weinberger Cc: Lennart Poettering, Ramkumar Ramachandra, LKML, Al Viro 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-23 5:47 ` richard -rw- weinberger @ 2013-07-23 7:57 ` Al Viro 2013-07-24 16:49 ` Lennart Poettering 0 siblings, 1 reply; 21+ messages in thread From: Al Viro @ 2013-07-23 7:57 UTC (permalink / raw) To: richard -rw- weinberger Cc: Richard Weinberger, Lennart Poettering, Ramkumar Ramachandra, LKML 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-23 7:57 ` Al Viro @ 2013-07-24 16:49 ` Lennart Poettering 0 siblings, 0 replies; 21+ messages in thread From: Lennart Poettering @ 2013-07-24 16:49 UTC (permalink / raw) To: Al Viro Cc: richard -rw- weinberger, Richard Weinberger, Ramkumar Ramachandra, LKML 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-23 5:40 ` Richard Weinberger 2013-07-23 5:47 ` richard -rw- weinberger @ 2013-07-24 16:38 ` Lennart Poettering 1 sibling, 0 replies; 21+ messages in thread From: Lennart Poettering @ 2013-07-24 16:38 UTC (permalink / raw) To: Richard Weinberger; +Cc: Ramkumar Ramachandra, LKML 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 9:45 ` Ramkumar Ramachandra 2013-07-22 10:38 ` Richard Weinberger @ 2013-07-22 12:40 ` Al Viro 2013-07-22 13:02 ` Ramkumar Ramachandra 1 sibling, 1 reply; 21+ messages in thread From: Al Viro @ 2013-07-22 12:40 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: LKML, Richard Weinberger 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 12:40 ` Al Viro @ 2013-07-22 13:02 ` Ramkumar Ramachandra 2013-07-22 13:20 ` Richard Weinberger 0 siblings, 1 reply; 21+ messages in thread From: Ramkumar Ramachandra @ 2013-07-22 13:02 UTC (permalink / raw) To: Al Viro; +Cc: LKML, Richard Weinberger 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 13:02 ` Ramkumar Ramachandra @ 2013-07-22 13:20 ` Richard Weinberger 2013-07-22 13:42 ` Ramkumar Ramachandra 0 siblings, 1 reply; 21+ messages in thread From: Richard Weinberger @ 2013-07-22 13:20 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Al Viro, LKML 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 13:20 ` Richard Weinberger @ 2013-07-22 13:42 ` Ramkumar Ramachandra 2013-07-22 14:08 ` Richard Weinberger 0 siblings, 1 reply; 21+ messages in thread From: Ramkumar Ramachandra @ 2013-07-22 13:42 UTC (permalink / raw) To: Richard Weinberger; +Cc: Al Viro, LKML 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 13:42 ` Ramkumar Ramachandra @ 2013-07-22 14:08 ` Richard Weinberger 2013-07-22 15:33 ` Ramkumar Ramachandra 0 siblings, 1 reply; 21+ messages in thread From: Richard Weinberger @ 2013-07-22 14:08 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Al Viro, LKML 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 14:08 ` Richard Weinberger @ 2013-07-22 15:33 ` Ramkumar Ramachandra 2013-07-22 19:29 ` Richard Weinberger 0 siblings, 1 reply; 21+ messages in thread From: Ramkumar Ramachandra @ 2013-07-22 15:33 UTC (permalink / raw) To: Richard Weinberger; +Cc: Al Viro, LKML 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 15:33 ` Ramkumar Ramachandra @ 2013-07-22 19:29 ` Richard Weinberger 2013-07-22 20:01 ` Ramkumar Ramachandra 0 siblings, 1 reply; 21+ messages in thread From: Richard Weinberger @ 2013-07-22 19:29 UTC (permalink / raw) To: Ramkumar Ramachandra; +Cc: Al Viro, LKML 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] um: change defconfig to stop spawning xterm 2013-07-22 19:29 ` Richard Weinberger @ 2013-07-22 20:01 ` Ramkumar Ramachandra 0 siblings, 0 replies; 21+ messages in thread From: Ramkumar Ramachandra @ 2013-07-22 20:01 UTC (permalink / raw) To: Richard Weinberger; +Cc: Al Viro, LKML 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2013-07-24 16:49 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.