From: Richard Weinberger <richard@nod.at>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
LKML <linux-kernel@vger.kernel.org>,
Jeff Dike <jdike@addtoit.com>
Subject: Re: [PATCH] um/configs: don't use devtmpfs in defconfig
Date: Tue, 16 Jul 2013 20:20:47 +0200 [thread overview]
Message-ID: <51E58EFF.1040703@nod.at> (raw)
In-Reply-To: <CALkWK0mY8OgqUiOAmyLzZpaS1U7Vw_xPSHytqggikGWBoghd_g@mail.gmail.com>
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
next prev parent reply other threads:[~2013-07-16 18:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 16:52 [PATCH] um/configs: don't use devtmpfs in defconfig Ramkumar Ramachandra
2013-07-16 16:58 ` Richard Weinberger
2013-07-16 17:06 ` Ramkumar Ramachandra
2013-07-16 17:08 ` Richard Weinberger
2013-07-16 17:15 ` Ramkumar Ramachandra
2013-07-16 17:20 ` Ramkumar Ramachandra
2013-07-16 17:23 ` Richard Weinberger
2013-07-16 17:36 ` Ramkumar Ramachandra
2013-07-16 17:39 ` Richard Weinberger
2013-07-16 17:31 ` Ramkumar Ramachandra
2013-07-16 17:34 ` Richard Weinberger
2013-07-16 17:47 ` Al Viro
2013-07-16 18:12 ` Ramkumar Ramachandra
2013-07-16 18:20 ` Richard Weinberger [this message]
2013-07-16 19:29 ` Ramkumar Ramachandra
2013-07-16 19:32 ` Richard Weinberger
2013-07-16 19:03 ` Al Viro
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=51E58EFF.1040703@nod.at \
--to=richard@nod.at \
--cc=artagnon@gmail.com \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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