[PATCH] um/configs: don't use devtmpfs in defconfig

[PATCH] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Avoid creating lots of bogus devices nodes like /dev/tty* (since
User-Mode Linux does not have virtual consoles.

Cc: Richard Weinberger <richard@nod.at>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 Applies on top of the patch I posted earlier.

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

diff --git a/arch/um/configs/i386_defconfig b/arch/um/configs/i386_defconfig
index 995aecd..93f4f97 100644
--- a/arch/um/configs/i386_defconfig
+++ b/arch/um/configs/i386_defconfig
@@ -293,8 +293,7 @@ CONFIG_HOSTAUDIO=m
 # Generic Driver Options
 #
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_DEVTMPFS=y
-CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_DEVTMPFS is not set
 CONFIG_STANDALONE=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 CONFIG_FW_LOADER=y
diff --git a/arch/um/configs/x86_64_defconfig b/arch/um/configs/x86_64_defconfig
index f2c6123..17650a6 100644
--- a/arch/um/configs/x86_64_defconfig
+++ b/arch/um/configs/x86_64_defconfig
@@ -285,8 +285,7 @@ CONFIG_HOSTAUDIO=m
 # Generic Driver Options
 #
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_DEVTMPFS=y
-CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_DEVTMPFS is not set
 CONFIG_STANDALONE=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 CONFIG_FW_LOADER=y
-- 
1.8.3.3.754.g9c3c367

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Richard Weinberger]

Am 16.07.2013 18:52, schrieb Ramkumar Ramachandra:
> Avoid creating lots of bogus devices nodes like /dev/tty* (since
> User-Mode Linux does not have virtual consoles.
> 
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Jeff Dike <jdike@addtoit.com>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---

NAK.

If you don't want devtmpfs, just disable it in your config.

Thanks,
//richard

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> If you don't want devtmpfs, just disable it in your config.

I don't understand: is this not a good default?  Why is creating bogus
devices, confusing systemd, and making um Linux hard to boot
desirable?

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Richard Weinberger]

Am 16.07.2013 19:06, schrieb Ramkumar Ramachandra:
> Richard Weinberger wrote:
>> If you don't want devtmpfs, just disable it in your config.
> 
> I don't understand: is this not a good default?  Why is creating bogus
> devices, confusing systemd, and making um Linux hard to boot
> desirable?
> 

Why does this confuse systemd? systemd has also a dependency on devtmpfs.

Thanks,
//richard

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> Why does this confuse systemd? systemd has also a dependency on devtmpfs.

See getty@.service, which is a dependency of getty.target:

  # On systems without virtual consoles, don't start any getty. (Note
  # that serial gettys are covered by serial-getty@.service, not this
  # unit
  ConditionPathExists=/dev/tty0

No, systemd does not have a hard dependency on devtmpfs.  See
src/getty-generator/getty-generator.c:

  if (detect_container(NULL) > 0) {
          log_debug("Automatically adding console shell.");

          if (add_symlink("console-getty.service", "console-getty.service") < 0)
                  r = EXIT_FAILURE;

          /* Don't add any further magic if we are in a container */
          goto finish;
  }

I can add a rule for detect_vm() and id = "uml" here, so that um Linux
runs console-getty.service out-of-the-box.  After I do that,
systemd-vconsole-setup.service will fail precisely because systemd
sees a /dev/tty0 and gets confused.

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> No, systemd does not have a hard dependency on devtmpfs.

Wait, let me double-check that.

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Richard Weinberger]

Am 16.07.2013 19:20, schrieb Ramkumar Ramachandra:
> Ramkumar Ramachandra wrote:
>> No, systemd does not have a hard dependency on devtmpfs.
> 
> Wait, let me double-check that.
> 

BTW: I'll not apply any patch to the kernel if the issue can easily
fixed in user space, that's the major reason for my NAK.

Thanks,
//richard

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> BTW: I'll not apply any patch to the kernel if the issue can easily
> fixed in user space, that's the major reason for my NAK.

I was just asking for good defaults; I want um Linux to work
out-of-the-box.  There's really no point in creating bogus devices in
/dev, and make life unnecessarily hard for user-space applications:
instead of checking for existence, they'd have to check that all the
devices work.  I doubt systemd will accept such a patch, just to bend
over backwards and support um.

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Richard Weinberger]

Am 16.07.2013 19:36, schrieb Ramkumar Ramachandra:
> Richard Weinberger wrote:
>> BTW: I'll not apply any patch to the kernel if the issue can easily
>> fixed in user space, that's the major reason for my NAK.
> 
> I was just asking for good defaults; I want um Linux to work
> out-of-the-box.  There's really no point in creating bogus devices in
> /dev, and make life unnecessarily hard for user-space applications:
> instead of checking for existence, they'd have to check that all the
> devices work.  I doubt systemd will accept such a patch, just to bend
> over backwards and support um.

Out of the box wont work in all cases.
But you can easily adjust some systemd units.
Like any visualization technology UML comes with some trade-offs.

Thanks,
//richard

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
>> No, systemd does not have a hard dependency on devtmpfs.
>
> Wait, let me double-check that.

Sorry about the stupidity; devtmpfs is very much a hard dependency.  I
just realized that CONFIG_VT is on, and can't be turned off (!).  See
drivers/tty/Kconfig:

  config VT
  	  bool "Virtual terminal" if EXPERT
	  depends on !S390 && !UML

Wait, shouldn't it be always off then?

*scratches head*

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Richard Weinberger]

Am 16.07.2013 19:31, schrieb Ramkumar Ramachandra:
> Ramkumar Ramachandra wrote:
>> Ramkumar Ramachandra wrote:
>>> No, systemd does not have a hard dependency on devtmpfs.
>>
>> Wait, let me double-check that.
> 
> Sorry about the stupidity; devtmpfs is very much a hard dependency.  I
> just realized that CONFIG_VT is on, and can't be turned off (!).  See
> drivers/tty/Kconfig:
> 
>   config VT
>   	  bool "Virtual terminal" if EXPERT
> 	  depends on !S390 && !UML
> 
> Wait, shouldn't it be always off then?

/me hands you a fresh cup of coffee over. :-)
Please note the depends on !UML.

Thanks,
//richard

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Al Viro]

On Tue, Jul 16, 2013 at 10:36:25PM +0530, Ramkumar Ramachandra wrote:
> Richard Weinberger wrote:
> > If you don't want devtmpfs, just disable it in your config.
> 
> I don't understand: is this not a good default?  Why is creating bogus
> devices, confusing systemd, and making um Linux hard to boot
> desirable?

As for the devices, they are *not* bogus.  RTFM, already.
Documentation/virtual/uml/UserModeLinux-HOWTO.txt, if you can't be bothered
to say git grep UML Documentation/ and find where it on your own.  The
relevant section is called "Setting up serial lines and consoles".
Seriously, it's not as if the documentation didn't exist or had been
hard to find...

FWIW, default config is rather annoying - 6 xterms spawned and associated
with /dev/tty[1-6].  con0=fd:0,fd:1 con=pts mentioned in the HOWTO would,
IMO, make for much saner default.

No comments on systemd behaviour - take that with LP and his crowd.  They
may or may not be confused by /dev/tty1 not being a virtual console.  One
practical issue is the lack of VT102 emulation; TERM=linux when logged
in on those is not right - you want either TERM=xterm (for xterms) or
TERM=screen (when accessing pts-associated ones with screen /dev/pts/n),
etc.  In any case, it's a dumb serial line as far as the guest kernel
is concerned - all terminal emulation is going to happen elsewhere (xterms
running on host and interpreting escape sequences from guest userland,
etc.)

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Al Viro wrote:
> As for the devices, they are *not* bogus.  RTFM, already.
> Documentation/virtual/uml/UserModeLinux-HOWTO.txt, if you can't be bothered
> to say git grep UML Documentation/ and find where it on your own.  The
> relevant section is called "Setting up serial lines and consoles".
> Seriously, it's not as if the documentation didn't exist or had been
> hard to find...

Yes; I've been trying to decipher the con thing for some time now.

> FWIW, default config is rather annoying - 6 xterms spawned and associated
> with /dev/tty[1-6].  con0=fd:0,fd:1 con=pts mentioned in the HOWTO would,
> IMO, make for much saner default.

Leave aside the fact that I could not find the uml-utils upstream [1],
and didn't have a /uml/port-helper to connect the xterms for a second;
I didn't even understand what was supposed to happen.  Why do we spawn
xterms, and attach to the host's /dev/tty*?  So far, I just used
/dev/console inside my existing tmux session in urxvt, and it seems to
work fine.

> No comments on systemd behaviour - take that with LP and his crowd.  They
> may or may not be confused by /dev/tty1 not being a virtual console.

>From my brief discussion with Lennart, he's just following what
Documentation/devices.txt says: /dev/tty* are virtual consoles.  If um
is making some sort of exception for good reason, I'm sure systemd can
accommodate it.

> One
> practical issue is the lack of VT102 emulation;

This detail is not at all clear from the Documentation.  I spent a lot
of time trying to figure out why systemd wasn't able to getty on
/dev/tty1.

> TERM=linux when logged
> in on those is not right - you want either TERM=xterm (for xterms) or
> TERM=screen (when accessing pts-associated ones with screen /dev/pts/n),
> etc.  In any case, it's a dumb serial line as far as the guest kernel
> is concerned - all terminal emulation is going to happen elsewhere (xterms
> running on host and interpreting escape sequences from guest userland,
> etc.)

Hm, what does $TERM have to do with all this?

[1]: A fabulously empty git repository here:
sourceforge.net/p/user-mode-linux/git/ref/master/

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Richard Weinberger]

Am 16.07.2013 20:12, schrieb Ramkumar Ramachandra:
> Al Viro wrote:
>> As for the devices, they are *not* bogus.  RTFM, already.
>> Documentation/virtual/uml/UserModeLinux-HOWTO.txt, if you can't be bothered
>> to say git grep UML Documentation/ and find where it on your own.  The
>> relevant section is called "Setting up serial lines and consoles".
>> Seriously, it's not as if the documentation didn't exist or had been
>> hard to find...
> 
> Yes; I've been trying to decipher the con thing for some time now.
> 
>> FWIW, default config is rather annoying - 6 xterms spawned and associated
>> with /dev/tty[1-6].  con0=fd:0,fd:1 con=pts mentioned in the HOWTO would,
>> IMO, make for much saner default.
> 
> Leave aside the fact that I could not find the uml-utils upstream [1],

http://user-mode-linux.sourceforge.net/downloads.html

> and didn't have a /uml/port-helper to connect the xterms for a second;
> I didn't even understand what was supposed to happen.  Why do we spawn
> xterms, and attach to the host's /dev/tty*?  So far, I just used
> /dev/console inside my existing tmux session in urxvt, and it seems to
> work fine.
> 
>> No comments on systemd behaviour - take that with LP and his crowd.  They
>> may or may not be confused by /dev/tty1 not being a virtual console.
> 
> From my brief discussion with Lennart, he's just following what
> Documentation/devices.txt says: /dev/tty* are virtual consoles.  If um
> is making some sort of exception for good reason, I'm sure systemd can
> accommodate it.

/me wonders since when /dev/ttyS0 is a virtual console...

Thanks,
//richard

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> http://user-mode-linux.sourceforge.net/downloads.html

I found a uml_utilities_20070815.tar.bz2.  2007, seriously?  Is there
no interest in maintaining it?

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Richard Weinberger]

Am 16.07.2013 21:29, schrieb Ramkumar Ramachandra:
> Richard Weinberger wrote:
>> http://user-mode-linux.sourceforge.net/downloads.html
> 
> I found a uml_utilities_20070815.tar.bz2.  2007, seriously?  Is there
> no interest in maintaining it?

What patches are missing?
Maintaining != Applying a patch every day.
Have you ever seen djb's software?

Thanks,
//richard

Re: [PATCH] um/configs: don't use devtmpfs in defconfig

[Al Viro]

On Tue, Jul 16, 2013 at 11:42:55PM +0530, Ramkumar Ramachandra wrote:
> Leave aside the fact that I could not find the uml-utils upstream [1],
> and didn't have a /uml/port-helper to connect the xterms for a second;
> I didn't even understand what was supposed to happen.  Why do we spawn
> xterms, and attach to the host's /dev/tty*?  So far, I just used
> /dev/console inside my existing tmux session in urxvt, and it seems to
> work fine.

There are several things that can be attached to them.  Again, see the
HOWTO for details.  FWIW, I prefer to have console in whatever I'm
launching the whole thing in (usually - ssh session to the box I'm
using to run all kinds of testing stuff on) with tty[1-6] attached to
pts and accessed via screen /dev/pts/<n> on the same box (again, from ssh
sessions, obviously).

> > One
> > practical issue is the lack of VT102 emulation;
> 
> This detail is not at all clear from the Documentation.  I spent a lot
> of time trying to figure out why systemd wasn't able to getty on
> /dev/tty1.

No fscking idea - sysvinit has no problem with launching getty instances
(on explicit lines in inittab, that is), so it's not a problem on getty
side of things.  And as much as I dislike systemd, I think it's not to blame
in this case.  It looks like it *does* lauch getty just fine, but your host
is misconfigured in a way that makes attempts to open the corresponding device
nodes fail.  With the messages you've quoted.  The same HOWTO has
     2.3 Compiling and installing uml_utilities
right after
     2.1 Compiling the kernel
     2.2 Compiling and installing kernel modules
so it's not as if the needed setup had not been mentioned.

FWIW, it would be a good idea to package the damn thing for Fedora -
Debian has
$ apt-cache search 'User-Mode Linux'
rootstrap - A tool for building complete Linux filesystem images
uml-utilities - User-mode Linux (utility programs)
user-mode-linux-doc - User-mode Linux (Documentation)
user-mode-linux - User-mode Linux (kernel)
$

> > TERM=linux when logged
> > in on those is not right - you want either TERM=xterm (for xterms) or
> > TERM=screen (when accessing pts-associated ones with screen /dev/pts/n),
> > etc.  In any case, it's a dumb serial line as far as the guest kernel
> > is concerned - all terminal emulation is going to happen elsewhere (xterms
> > running on host and interpreting escape sequences from guest userland,
> > etc.)
> 
> Hm, what does $TERM have to do with all this?

Huh?  That's what tells all curses-based stuff which escape sequences to
emit.  And that's the *only* thing in which "it's not a VT" matters at
all.  Again, your description of symptoms doesn't look like "systemd gets
confused by tty1 not being a VT and fails to launch getty"; it appears to
be "systemd does see tty1 and does launch getty, albeit with slightly wrong
terminal type argument.  Which doesn't matter, since getty fails to open the
device nodes due to missing utilities on host".  Install said utilities
or switch to explicit con=... in command line and getty will launch just
fine.  That's where TERM= settings come into play - some curses-based stuff
will assume it has all linux VT escape sequences to play with and the
thing you are using to access it might not be happy.  Other than that
(and this is the thing you pass to getty as terminal type - the last
argument for agetty(8)), everything seems to boil down to lack of uml utils
on host...