linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Pierre Paul MINGOT <mingot.pierre@gmail.com>,
	jslaby@suse.cz, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Add possibility to set /dev/tty number
Date: Wed, 6 Jan 2016 09:07:28 -0500	[thread overview]
Message-ID: <568D1FA0.3030407@gmail.com> (raw)
In-Reply-To: <20160106135439.52231ba2@lxorguk.ukuu.org.uk>

On 2016-01-06 08:54, One Thousand Gnomes wrote:
>> In fact, there already appears to be some degree of allocation on demand
>> for VT's (otherwise deallocvt has no point), just not for everything
>> associated with the VT.  I'd be willing to bet that almost everything
>> that reasonably can be dynamically allocated already is, there is a bare
>> minimum required for even a virtual device after all.
>
> If there is 1.6K overhead per vt coming from somewhere (given we only
> preallocate 1 VT) then either
>
> - There is stuff not being dynamically allocated (which you can find and
>    fix)
>
> - Your userspace is triggering those dynamic allocations
>
> There is no magic thing that requires 1.6K of kernel data per console.
There is a bare minimum structure required for something to be 
associated with a device node. The device nodes exist regardless, and 
the dynamic allocation of the other things (like the screen state, the 
output buffer, etc) gets triggered on first access to the node. 1.6k is 
probably not the absolute minimum it could be, but there are still 
things that need to be there for it to behave the way it's supposed to. 
  At a minimum, you need stuff to associate the device numbers, handle 
the tty ioctls, handle device node access, and probably an associated 
lock or two to maintain consistency.  None of that can reasonably be 
dynamically allocated without multiplexing everything through a single 
underlying virtual device (kind of like is done with PTY's) or adding 
some new system calls to manage it, except that that would change the 
userspace API, and thus be a regression.


  reply	other threads:[~2016-01-06 14:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-04 15:34 [PATCH] Add possibility to set /dev/tty number Pierre Paul MINGOT
2016-01-04 15:43 ` Greg KH
2016-01-04 16:57   ` Austin S. Hemmelgarn
2016-01-04 17:11     ` Greg KH
2016-01-04 18:41       ` Austin S. Hemmelgarn
2016-01-04 22:55         ` One Thousand Gnomes
2016-01-05 13:16           ` Austin S. Hemmelgarn
2016-01-05 15:24             ` Greg KH
2016-01-05 15:33               ` Austin S. Hemmelgarn
2016-01-05 16:11             ` Theodore Ts'o
2016-01-05 16:22               ` Austin S. Hemmelgarn
2016-01-05  8:51         ` Pierre Paul MINGOT
2016-01-05 13:02           ` Austin S. Hemmelgarn
2016-01-05 15:25           ` Greg KH
2016-01-05 15:43             ` Austin S. Hemmelgarn
2016-01-05 16:03               ` Greg KH
2016-01-05 18:38         ` Austin S. Hemmelgarn
2016-01-05 20:47           ` One Thousand Gnomes
2016-01-06 12:42             ` Austin S. Hemmelgarn
2016-01-06 13:54               ` One Thousand Gnomes
2016-01-06 14:07                 ` Austin S. Hemmelgarn [this message]
2016-01-06 13:39 ` Austin S. Hemmelgarn

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=568D1FA0.3030407@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingot.pierre@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).