TTY: export NR_LDISC and N_* line discipline numbers to user-space
PATCH 1/1 TTY: export NR_LDISC and N_* line discipline numbers to user-space
From: Florian Fainelli <[email protected]>
Since commit (4564f9e5: consolidate line discipline number definitions) the patch moved all line discipline number from a per-architecture termios.h to a shared one: tty.h. However, prior to this consolidation work, the line discipline numbers were outside of an ifdef __KERNEL__/endif block so these numbers used to be exported to user-space.
Since such numbers are kernel ABI anyway, and tty.h is already included for user- space header processing, just move these relevant defines outside of the ifdef __KERNEL__/endif block in include/linux/tty.h.
---
include/linux/tty.h +19 -18
@@ -5,24 +5,6 @@* 'tty.h' defines some structures used by tty_io.c and some defines. */ -#ifdef __KERNEL__ -#include <linux/fs.h> -#include <linux/major.h> -#include <linux/termios.h> -#include <linux/workqueue.h> -#include <linux/tty_driver.h> -#include <linux/tty_ldisc.h> -#include <linux/mutex.h> - -#include <asm/system.h> - - -/* -* (Note: the *_driver.minor_start values 1, 64, 128, 192 are -* hardcoded at present.) -*/ -#define NR_UNIX98_PTY_DEFAULT 4096/* Default maximum for Unix98 ptys */ -#define NR_UNIX98_PTY_MAX (1 << MINORBITS)/* Absolute limit */ #define NR_LDISCS 30/* line disciplines */
@@ -51,6 +33,25 @@#define N_GSM0710 21/* GSM 0710 Mux */ #define N_TI_WL 22/* for TI's WL BT, FM, GPS combo chips */ +#ifdef __KERNEL__ +#include <linux/fs.h> +#include <linux/major.h> +#include <linux/termios.h> +#include <linux/workqueue.h> +#include <linux/tty_driver.h> +#include <linux/tty_ldisc.h> +#include <linux/mutex.h> + +#include <asm/system.h> + + +/* +* (Note: the *_driver.minor_start values 1, 64, 128, 192 are +* hardcoded at present.) +*/ +#define NR_UNIX98_PTY_DEFAULT 4096/* Default maximum for Unix98 ptys */ +#define NR_UNIX98_PTY_MAX (1 << MINORBITS)/* Absolute limit */ +/* * This character is the same as _POSIX_VDISABLE: it cannot be used as * a c_cc[] character, but indicates that a particular special character
Signature · 1 line
1.7.4.1
Quoted 11 lines · Florian Fainelli
From: Florian Fainelli <[email protected]>
Since commit (
4564f9e5: consolidate line discipline number definitions) the patch moved all line discipline number from a per-architecturetermios.hto a shared one:tty.h. However, prior to this consolidation work, the line discipline numbers were outside of an ifdef __KERNEL__/endif block so these numbers used to be exported to user-space.Since such numbers are kernel ABI anyway, and
tty.his already included for user- space header processing, just move these relevant defines outside of the ifdef __KERNEL__/endif block ininclude/linux/tty.h.
Any reason you didn't copy _any_ of the people who signed off on that patch, or the original author of that patch?
Anyway, this is been this way for four years, since the 2.6.21 kernel release. Since no one has noticed, or complained, since then, how much a problem is this really?
Meaning, why has it taken this long for anyone to notice?
thanks,
greg k-h
Hello,
Quoted 10 lines · On Tuesday 24 May 2011 14:40:44 Greg KH wrote:
Quoted 9 lines · Florian Fainelli
From: Florian Fainelli <[email protected]>
Since commit (
4564f9e5: consolidate line discipline number definitions) the patch moved all line discipline number from a per-architecturetermios.hto a shared one:tty.h. However, prior to this consolidation work, the line discipline numbers were outside of an ifdef __KERNEL__/endif block so these numbers used to be exported to user-space.
Quoted 6 lines
Quoted 3 lines
Since such numbers are kernel ABI anyway, and
tty.his already included for user- space header processing, just move these relevant defines outside of the ifdef __KERNEL__/endif block ininclude/linux/tty.h.Any reason you didn't copy _any_ of the people who signed off on that patch, or the original author of that patch?
No particular reason but my mistake, fixed that.
Quoted 4 lines
Anyway, this is been this way for four years, since the 2.6.21 kernel release. Since no one has noticed, or complained, since then, how much a problem is this really?
This is a problem because you may have out of tree drivers using a line discpline number, and you do not want your companion user-space application to have to use a different line discpline number but the one the kernel should provide.
Quoted 2 lines
Meaning, why has it taken this long for anyone to notice?
- long standing user-space applications such as pppd got their N_PPP long ago, and do not have to worry about N_PPP being renumbered so they can just define it in pppd's sources it won't break
- I started implementing a line discipline driver only a couple of months ago and then realized that such ABI should have been exported
--
Florian
Quoted 33 lines · Florian Fainelli
Hello,
Quoted 10 lines · On Tuesday 24 May 2011 14:40:44 Greg KH wrote:
Quoted 9 lines · Florian Fainelli
From: Florian Fainelli <[email protected]>
Since commit (
4564f9e5: consolidate line discipline number definitions) the patch moved all line discipline number from a per-architecturetermios.hto a shared one:tty.h. However, prior to this consolidation work, the line discipline numbers were outside of an ifdef __KERNEL__/endif block so these numbers used to be exported to user-space.Quoted 6 lines
Quoted 3 lines
Since such numbers are kernel ABI anyway, and
tty.his already included for user- space header processing, just move these relevant defines outside of the ifdef __KERNEL__/endif block ininclude/linux/tty.h.Any reason you didn't copy _any_ of the people who signed off on that patch, or the original author of that patch?
No particular reason but my mistake, fixed that.
Quoted 4 lines
Anyway, this is been this way for four years, since the 2.6.21 kernel release. Since no one has noticed, or complained, since then, how much a problem is this really?
This is a problem because you may have out of tree drivers using a line discpline number, and you do not want your companion user-space application to have to use a different line discpline number but the one the kernel should provide.
Quoted 1 line
Quoted 8 lines
Quoted 1 line
Meaning, why has it taken this long for anyone to notice?
- long standing user-space applications such as pppd got their
N_PPPlong ago, and do not have to worry aboutN_PPPbeing renumbered so they can just define it in pppd's sources it won't break- I started implementing a line discipline driver only a couple of months ago and then realized that such ABI should have been exported
Ok, then it really isn't that important of a change :)
I'll queue it up for the next major merge window after this one, thanks.
greg k-h
Quoted 40 lines · On Tuesday 24 May 2011 15:33:53 Greg KH wrote:
Quoted 39 lines · Florian Fainelli
Hello,
Quoted 11 lines · On Tuesday 24 May 2011 14:40:44 Greg KH wrote:
Quoted 10 lines · Florian Fainelli
From: Florian Fainelli <[email protected]>
Since commit (
4564f9e5: consolidate line discipline number definitions) the patch moved all line discipline number from a per-architecturetermios.hto a shared one:tty.h. However, prior to this consolidation work, the line discipline numbers were outside of an ifdef
__KERNEL__/endif block so these numbers used to be exported to user-space.Quoted 7 lines
Quoted 4 lines
Since such numbers are kernel ABI anyway, and
tty.his already included for user- space header processing, just move these relevant defines outside of the ifdef __KERNEL__/endif block ininclude/linux/tty.h.Any reason you didn't copy _any_ of the people who signed off on that patch, or the original author of that patch?
No particular reason but my mistake, fixed that.
Quoted 3 lines
Anyway, this is been this way for four years, since the 2.6.21 kernel release. Since no one has noticed, or complained, since then, how much a problem is this really?
This is a problem because you may have out of tree drivers using a line discpline number, and you do not want your companion user-space application to have to use a different line discpline number but the one the kernel should provide.
Quoted 1 line
Meaning, why has it taken this long for anyone to notice?
- long standing user-space applications such as pppd got their
N_PPPlong ago, and do not have to worry aboutN_PPPbeing renumbered so they can just define it in pppd's sources it won't break
Quoted 6 lines
Quoted 2 lines
- I started implementing a line discipline driver only a couple of months ago and then realized that such ABI should have been exported
Ok, then it really isn't that important of a change :)
I'll queue it up for the next major merge window after this one, thanks.
Thanks!
--
Florian
Tilman Schmidt
Acked-byAm 24.05.2011 15:17 schrieb Florian Fainelli:
Quoted 14 lines · On Tuesday 24 May 2011 14:40:44 Greg KH wrote:
Quoted 13 lines · Florian Fainelli
Quoted 12 lines
From: Florian Fainelli <[email protected]>
Since commit (
4564f9e5: consolidate line discipline number definitions) the patch moved all line discipline number from a per-architecturetermios.hto a shared one:tty.h. However, prior to this consolidation work, the line discipline numbers were outside of an ifdef __KERNEL__/endif block so these numbers used to be exported to user-space.Since such numbers are kernel ABI anyway, and
tty.his already included for user- space header processing, just move these relevant defines outside of the ifdef __KERNEL__/endif block ininclude/linux/tty.h.
[...]
Quoted 5 lines
Quoted 1 line
Meaning, why has it taken this long for anyone to notice?
- long standing user-space applications such as pppd got their
N_PPPlong ago, and do not have to worry aboutN_PPPbeing renumbered so they can just define it in pppd's sources it won't break
Also, I just checked on openSUSE 11.2, which comes with kernel release is 2.6.27, and it still defines the LD numbers in /usr/include/bits/ioctl-types.h (included from sys/ioctl.h). I guess other distributions are doing the same, so their users wouldn't notice the change.
Anyway, the patch is fine by me. Feel free to add:
Thanks,
Tilman
Signature · 4 lines
Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)