Date: Mon, 1 May 2017 10:13:50 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Brooks Davis <brooks@freebsd.org> Cc: Julian Elischer <julian@freebsd.org>, freebsd-net@freebsd.org, freebsd-atm@freebsd.org Subject: Re: The fate of ngatm Message-ID: <201705011713.v41HDohb091028@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <20170501160403.GB77098@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
-- Start of PGP signed section. > On Sun, Apr 30, 2017 at 12:47:51AM +0800, Julian Elischer wrote: > > On 28/4/17 2:00 am, Brooks Davis wrote: > > > As previous threatened, I've removed support for NATM (as well as a > > > remarkable number of remnants of the old ATM framework). One piece > > > that still remains is the ngatm framework in netgraph. This includes > > > the ng_ccatm(4), ng_sscfu(4), ng_sscop(4), and ng_uni(4) nodes. > > > > > > These don't attach to physical interfaces and didn't depend on the NATM > > > interface code so I left them alone in the first cut. My question > > > is, are they useful without physical interfaces? If so, keeping them > > > doesn't appear to have a high support burden. If not, we should remove > > > them. > > > > I don't know if people are using these now, but at one stage people > > were using them to decode/encode atm higher level protocols over an > > ethernet transport to implement a PPPoA infrastructure. > > Just for clarity, I'm not talking about ng_atmllc(4) which is standalone > and a classic header adding/striping module. Does Juniper have any stake in this ATM code? Their routers do support ATM interfaces. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201705011713.v41HDohb091028>