All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Kay Sievers <kay@vrfy.org>
Cc: "Ted Ts'o" <tytso@mit.edu>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Konstantin Khlebnikov <khlebnikov@openvz.org>,
	Greg Kroah-Hartman <gregkh@linux-foundation.org>,
	Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Subject: Re: RFC: deprecating/removing the legacy mode of devpts
Date: Sun, 08 Apr 2012 11:00:52 -0700	[thread overview]
Message-ID: <4F81D254.9090000@zytor.com> (raw)
In-Reply-To: <CAPXgP12Zp7aHev8Sh=3W0zHA-vZoR9TpTW8c7ep9vTQQQScBPg@mail.gmail.com>

On 04/08/2012 12:30 AM, Kay Sievers wrote:
> 
> I don't think it has much to do with udev, it follows 100%
> instructions from the kernel, and it does not create the device node
> that is in the way here.
> 
> Udev does not name any device in the system since a long time. Since
> quite a while it has not even the code to do mknod() and requires
> devtmpfs. The device node part of udev these day is limited to manage
> device node permissions and creating additional symlinks. All device
> node creation happens inside the kernel itself - where it belongs -
> and not in userspace.
> 
> If the default behaviour of /dev/pts/* should be changed, the kernel
> should be changed to support the multi-instance mode right away
> without involving userspace. We better do not require userspace to
> gain any knowledge about such stuff. I'm confident, that we should not
> add more, or require to support multiple alternative ways of handling
> kernel internals in userspace.
> 
> So, I think we either remove the '/sys/class/tty/ptmx' device from the
> system, and let the devpts code create the symlink in the 'devtmpfs'
> filesystem, or alternatively the '/sys/class/tty/ptmx' device supports
> the multi-instance mode itself, instead of requiring a symlink. Such
> stuff belongs entirely into the kernel these day. Anything else seems
> to just ask for trouble.
> 

OK, this seems very reasonable, and something that could (and probably
*has to*) be done as an atomic change... maybe.

There is no way for /dev/ptmx to support the multiinstance mode since it
is located outside any devpts filesystem; it *has* to be inside the
devpts filesystem in order to function... if that wasn't the case this
whole thing would have been trivial from the get-go.

Greg, do you have any insights in what would have to be necessary
mechanics to make this.

	-hpa


  reply	other threads:[~2012-04-08 18:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-07 18:36 RFC: deprecating/removing the legacy mode of devpts H. Peter Anvin
2012-04-07 19:20 ` Alan Cox
2012-04-07 20:02   ` H. Peter Anvin
2012-04-07 21:27     ` Ted Ts'o
2012-04-07 22:03       ` H. Peter Anvin
2012-04-08  7:30         ` Kay Sievers
2012-04-08 18:00           ` H. Peter Anvin [this message]
2012-04-08 19:16             ` Kay Sievers
2012-04-11 23:53               ` Greg Kroah-Hartman
2012-04-11 23:55                 ` H. Peter Anvin
2012-04-12  0:30                   ` Greg Kroah-Hartman
2012-04-12  0:38                     ` Kay Sievers
2012-04-12  1:14                       ` Greg Kroah-Hartman
2012-04-12  1:08               ` Al Viro
2012-04-12  1:56                 ` H. Peter Anvin
2012-04-12  2:26                   ` Al Viro
2012-04-12  2:48                     ` H. Peter Anvin
2012-04-12  3:04                       ` Al Viro
2012-04-12  3:07                         ` H. Peter Anvin
2012-04-12  2:27                 ` Kay Sievers
2012-04-12  2:45                   ` Al Viro
2012-04-12  2:48                     ` Kay Sievers
2012-04-12  2:53                   ` H. Peter Anvin
2012-04-12  3:02                     ` Kay Sievers
2012-04-08 17:20         ` Alan Cox
2012-04-07 20:04   ` H. Peter Anvin
2012-04-08 18:15 ` Konstantin Khlebnikov
2012-04-08 22:18   ` Alan Cox
2012-04-08 22:26     ` H. Peter Anvin
2012-04-08 22:46       ` Alan Cox
2012-04-08 22:45         ` H. Peter Anvin
2012-04-09  3:15           ` Theodore Tso
2012-04-09 12:43             ` Kay Sievers
2012-04-09 13:37               ` 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=4F81D254.9090000@zytor.com \
    --to=hpa@zytor.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@linux-foundation.org \
    --cc=kay@vrfy.org \
    --cc=khlebnikov@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=tytso@mit.edu \
    --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 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.