On Thu, 23 May 2024 10:01:51 +0200 Jiri Slaby <jirislaby@xxxxxxxxxx> wrote: > The driver definitely behaves as described. If the ldisc is used on a > real HW. ptys are a different story -- it's not guaranteed there. > Does it make sense to use nhdlc on a pty pair? I believe not. OK. Well, the use case was as follows: pppd has an option called `pty` that makes it execute an arbitrary program, connect to its standard input and output via a pty pair, and send and receive PPP frames over that pty pair. rp-pppoe (https://dianne.skoll.ca/projects/rp-pppoe/) includes a program called `pppoe` designed to be on the other end of that pty pair and receive/transmit the PPP frames via PPPoE. pppd includes a `sync` option, and pppoe a `-s` option that enable N_HDLC on the pty. This lets pppoe just read/write a frame at a time without worrying about PPP framing bytes or dealing with PPP escape characters, which reduces the CPU overhead of pppoe. Now, the Linux kernel has had built-in support for PPPoE for many years, and I was thinking of dropping userspace PPPoE support, but I heard from a user who wants to keep it. ucLinux, it seems, does not support dlopen(), so this user can't use pppd's `plugin` option to load the kernel-mode PPPoE support module and has to keep using user-space PPPoE. Sync support was added to pppoe decades ago and either it worked well, nobody used it, or nobody reported a bug until recently. But anyway, if the consensus is that N_HDLC shouldn't be used on a pty pair, I'm fine with that. Perhaps a comment in the source file and a note in the N_HDLC documentation would be good, and then I'll just remove support for `sync` and `-s` from pppoe, since it can't be guaranteed to work correctly. Regards, Dianne.
