From owner-freebsd-atm@freebsd.org Sat Apr 29 16:48:11 2017 Return-Path: Delivered-To: freebsd-atm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B2DCD56302; Sat, 29 Apr 2017 16:48:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DE0ADE43; Sat, 29 Apr 2017 16:48:10 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-148-214-220.dyn.iinet.net.au [124.148.214.220]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v3TGlv38060352 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 29 Apr 2017 09:48:06 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: The fate of ngatm To: Brooks Davis , freebsd-net@freebsd.org, freebsd-atm@freebsd.org References: <20170427180029.GB35387@spindle.one-eyed-alien.net> From: Julian Elischer Message-ID: <752628c6-f6a2-c4e4-e756-66b115428766@freebsd.org> Date: Sun, 30 Apr 2017 00:47:51 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170427180029.GB35387@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-atm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: ATM for FreeBSD! List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 16:48:11 -0000 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. > > -- Brooks 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. No idea if it's still being used .