Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1300830 > unrolled thread

[PATCH] Add possibility to set /dev/tty number

Back to article view | Back to linux.kernel

Contents

  [PATCH] Add possibility to set /dev/tty number Pierre Paul MINGOT <mingot.pierre@gmail.com> - 2016-01-04 16:40 +0100
    Re: [PATCH] Add possibility to set /dev/tty number Greg KH <gregkh@linuxfoundation.org> - 2016-01-04 16:50 +0100
      Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-04 18:00 +0100
        Re: [PATCH] Add possibility to set /dev/tty number Greg KH <gregkh@linuxfoundation.org> - 2016-01-04 18:20 +0100
          Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-04 19:50 +0100
            Re: [PATCH] Add possibility to set /dev/tty number One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-05 00:00 +0100
              Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-05 14:20 +0100
                Re: [PATCH] Add possibility to set /dev/tty number Greg KH <gregkh@linuxfoundation.org> - 2016-01-05 16:30 +0100
                  Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-05 16:40 +0100
                Re: [PATCH] Add possibility to set /dev/tty number Theodore Ts'o <tytso@mit.edu> - 2016-01-05 17:20 +0100
                  Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-05 17:30 +0100
            Re: [PATCH] Add possibility to set /dev/tty number Pierre Paul MINGOT <mingot.pierre@gmail.com> - 2016-01-05 10:00 +0100
              Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-05 14:10 +0100
              Re: [PATCH] Add possibility to set /dev/tty number Greg KH <gregkh@linuxfoundation.org> - 2016-01-05 16:30 +0100
                Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-05 16:50 +0100
                  Re: [PATCH] Add possibility to set /dev/tty number Greg KH <gregkh@linuxfoundation.org> - 2016-01-05 17:10 +0100
            Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-05 19:40 +0100
              Re: [PATCH] Add possibility to set /dev/tty number One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-05 21:50 +0100
                Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-06 13:50 +0100
                  Re: [PATCH] Add possibility to set /dev/tty number One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-06 15:00 +0100
                    Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-06 15:10 +0100
    Re: [PATCH] Add possibility to set /dev/tty number "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-06 14:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1302783

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.

--
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/

[toc] | [prev] | [next] | [standalone]

#1302772

On 2016-01-04 10:34, Pierre Paul MINGOT wrote:
> Hello,
> 
> In Linux there is no way to set the number of tty devices or console
> to create. By default the kernel create 64 /dev/tty devices. what is
> too much for embedded system with limited resources. As all these 64
> devices are not necessary or mandatory for the kernel proper working,
> I add a config option to set the desired tty. The lowest number you
> can set is 1 and the highest is 63, any value respectively below or
> above that, will cause a kconfig invalid entry pop-up.
> 
> Please keep me update.
> 
> Best Regards
> 
OK, circling back since I never commented on the original patch.  Greg covered most of the basics regarding formatting, so I won't comment on that.
 
>+config NR_TTY_DEVICES
>+    int "Maximum tty device number"
>+    depends on VT
>+    range 1 63
>+    default 1

The config item should default to the current value of 63, as it changes the userspace visible ABI otherwise.  It should also probably depend on EXPERT, as this isn't something that should be arbitrarily changed by most people building the kernel.

> #define MIN_NR_CONSOLES 1       /* must be at least 1 */
>-#define MAX_NR_CONSOLES	63	/* serial lines start at 64 */
>-#define MAX_NR_USER_CONSOLES 63	/* must be root to allocate above this */
>+/* serial lines start at 64 */
>+#define MAX_NR_CONSOLES	 CONFIG_NR_TTY_DEVICES
>+/* must be root to allocate above this */
>+#define MAX_NR_USER_CONSOLES CONFIG_NR_TTY_DEVICES

This shouldn't affect serial console numbering, as the minimum serial console minor number isn't defined relative to either of the values here.

Using #define to define things relative to Kconfig values in uapi headers doesn't work (at least, not just doing it with a simple #define, there might be some way to do it, but I have yet to see it), these would need to get parsed when the headers get installed, so this patch would result in MAX_NR_CONSOLES and MAX_NR_USER_CONSOLES being undefined in the userspace headers because userspace doesn't have direct access to any of the CONFIG values.
--
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/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web