From: Xie He
Sent: 05 November 2020 22:47
On Thu, Nov 5, 2020 at 12:40 PM Arnd Bergmann [off-list ref] wrote:
quoted
quoted
I think this driver never worked. Looking at the original code in
Linux 2.1.31, it already has the problems I fixed in commit
8fdcabeac398.
I guess when people (or bots) say they "tested", they have not
necessarily used this driver to actually try transporting data. They
may just have tested open/close, etc. to confirm that the particular
problem/issue they saw had been fixed.
It didn't sound like that from the commit message, but it could be.
For reference:
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit?id=aa2b4427c355acaf86d2c7e6fae
a3472005e3cff
I see. The author of this commit said "I tested by bringing up an x.25
async line using a modified version of slattach." Maybe he only
switched TTY ports from the N_TTY line discipline to the N_X25 line
discipline. To actually test transporting data, we need to either use
AF_PACKET sockets, or use AF_X25 sockets with the X.25 routing table
properly set up. The author of this commit didn't clearly indicate
that he did these.
Hmmm.... LAPB would expect to have an X.25 level 3 and maybe ISO
transport (class 0, 2 or 3) sat on top of it.
The ISO networking service would normally be absent (more likely to
be used with class 4 transport over ethernet - but still optional).
Nothing at all like SLIP.
You could use LAPB unnumbered (UI) frames to carry IP frames
(as SLIP does) - but that is really just using HDLC instead of
async. Doing that using async is just silly.
Looks like this code should have been removed for 2.2 :-)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)