[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56513ba35a864fce8e27c550b55766a1@AcuMS.aculab.com>
Date: Thu, 5 Nov 2020 22:35:23 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Xie He' <xie.he.0141@...il.com>
CC: Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>
Subject: RE: [PATCH net-next] net: x25_asy: Delete the x25_asy driver
From: Xie He
> Sent: 05 November 2020 19:35
>
> On Thu, Nov 5, 2020 at 1:10 AM David Laight <David.Laight@...lab.com> wrote:
> >
> > > This driver transports LAPB (X.25 link layer) frames over TTY links.
> >
> > I don't remember any requests to run LAPB over anything other
> > than synchronous links when I was writing LAPB implementation(s)
> > back in the mid 1980's.
> >
> > If you need to run 'comms over async uart links' there
> > are better options.
> >
> > I wonder what the actual use case was?
>
> I think this driver was just for experimental purposes. According to
> the author's comment at the beginning of x25_asy.c, this driver didn't
> implement FCS (frame check sequence), which was required by CCITT's
> standard. So I think this driver was not suitable for real-world use
> anyway.
Yes, you could get transparency by sending 0x7f bytes twice
(a bit like bisync) but you'd want the CRC to check for lost bytes.
I bet this was only ever used by the author and only to talk to itself.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists