Hello Bjørn and Ayush,

Bjørn Mork <[email protected]> writes:

> I don't know anything at all about this subject, but I believe the wan
> HDLC stuff is sync only.
>
> Noting that the ppp driver does all the async framing internally. And
> interleaved with ppp specific stuff, so probably not re-usable even if
> exported. Ref ppp_async_encode() in drivers/net/ppp/ppp_async.c
>
> I assume it would have used a shared implementation if there was one.
> But I could be wrong...

In fact I don't know of any async use of the hdlc_* code. However the
story with sync PPP in the kernel (paired with pppd program) was a bit
different. At first there was a separate syncppp code, used by all early
hw and drivers. This code implemented a simple PPP (a bare minimum
needed on leased lines) and a so called Cisco HDLC mode (which basically
only Cisco routers could use, and then Linux of course).
This was all mostly 64 kbps - 2 Mbps era equipment, 1993 or so.

Then there was the Frame Relay protocol and I wanted a very cheap PC
card (just $1000 or so at the time) to use it. So I wrote a (again, very
basic) FR code. I also needed a header-less HDLC code for specific
Ethernet-HDLC bridge devices, and this way "generic HDLC" started to
exist. Also, X.25 support was somehow added.

However, syncppp couldn't use generic HDLC (it worked the other way
around). Then, basically, I reimplemented the PPP part of syncppp
(I already had separate Cisco HDLC code for some reason), converted the
drivers and then asyncppp was removed.


The "Generic PPP" effort was completely independent. I think it was
centered around async dial-up modem connections, and thus included a lot
of relevant stuff - auth, character escaping, compression, connecting
and disconnecting on demand etc. Then the ADSL came with PPP over ATM
and over Ethernet.


At some point I was thinking about converting generic HDLC to use
generic PPP (instead of the simple implementation in hdlc_ppp.c). But it
was way too complicated for not much gain.


The generic HDLC doesn't care if the underlying device talks sync or
async. The driver would presumably just need to handle async HDLC
framing.
--
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa