From: Xie He
> Sent: 05 November 2020 22:47
>
> On Thu, Nov 5, 2020 at 12:40 PM Arnd Bergmann <a...@kernel.org> wrote:
> >
> > > 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)
