Re: [PATCH net-next RFC v4] net: hdlc_x25: Queue outgoing LAPB frames

[Xie He <xie.he.0141@gmail.com>]

On Sun, Feb 28, 2021 at 10:56 PM Martin Schiller <ms@dev.tdt.de> 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.