Clarification on line discipline enumeration

[frosch01]

I am a bit unsure on this "num" of an LDISC. In the kernel documentation, I found these words:

Do not re-use ldisc numbers as they are part of the userspace ABI and writing over an existing ldisc will cause demons to eat your computer. You must not re-register over the top of the line discipline even with the same data or your computer again will be eaten by demons.

When checking with the file /usr/include/linux/tty.h, which should be identical to kernel/include/uapi/linux/tty.h , I find these defined numbers on todays 6.x.x kernels:

`
/*

• 'tty.h' defines some structures used by tty_io.c and some defines.
  */

/* line disciplines /
#define N_TTY 0
#define N_SLIP 1
...
#define N_SLCAN 17 / Serial / USB serial CAN Adaptors /
...
#define N_NCI 25 / NFC NCI UART /
#define N_SPEAKUP 26 / Speakup communication with synths /
#define N_NULL 27 / Null ldisc used for error handling /
#define N_MCTP 28 / MCTP-over-serial /
#define N_DEVELOPMENT 29 / Manual out-of-tree testing /
#define N_CAN327 30 / ELM327 based OBD-II interfaces */

/* Always the newest line discipline + 1 */
#define NR_LDISCS 31

#endif /* _LINUX_TTY_H */
`

Currently, the sllin ldisc is using the numbers 28 and 29. This means, to my understanding, that the numbers for N_MCTP and N_DEVELOPMENT would be overridden, which should be avoided according to the kernel documentation.

Can you please point out what would be the right way for adding the sllin ldisc to a system?

Should the numbers be adapted to be beyond the already defined numbers?

And, as there is NR_LDISCS given, why not making N_SLLIN dependent on NR_LDISCS macro?

[xeno27]

Hi,
you are right they are already in use (the project is quite old).
I think @ppisa will not change the line response code, since the code is use in production.
As this code is not going to upstream, we can't reserve our own line response codes (as i understood from @hartkopp).
So if you use this in your system, and you are free to play around the Linux Kernel just add your own numbers at the end.
To use NR_LDISCS and NR_LDISCS +1 is a good idea ( but only a shourt term solution .. ) , maybe @ppisa or hartkopp@ has a though about that.