On Sun, Feb 28, 2021 at 10:56 PM Martin Schiller <ms@xxxxxxxxxx> wrote: > > >> Also, I have a hard time assessing if such a wrap is really > >> enforceable. > > > > Sorry. I don't understand what you mean. What "wrap" are you referring > > to? > > I mean the change from only one hdlc<x> interface to both hdlc<x> and > hdlc<x>_x25. > > I can't estimate how many users are out there and how their setup looks > like. I'm also thinking about solving this issue by adding new APIs to the HDLC subsystem (hdlc_stop_queue / hdlc_wake_queue) for hardware drivers to call instead of netif_stop_queue / netif_wake_queue. This way we can preserve backward compatibility. However I'm reluctant to change the code of all the hardware drivers because I'm afraid of introducing bugs, etc. When I look at the code of "wan/lmc/lmc_main.c", I feel I'm not able to make sure there are no bugs (related to stop_queue / wake_queue) after my change (and even before my change, actually). There are even serious style problems: the majority of its lines are indented by spaces. So I don't want to mess with all the hardware drivers. Hardware driver developers (if they wish to properly support hdlc_x25) should do the change themselves. This is not a problem for me, because I use my own out-of-tree hardware driver. However if I add APIs with no user code in the kernel, other developers may think these APIs are not necessary.
