Date: Tue, 4 Feb 2025 00:32:31 +0800 From: Zhenlei Huang <zlei@FreeBSD.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Any real usage of sppp(4) on architectures other than i386 or amd64 ? Message-ID: <57B63ECF-F2A2-43FB-8814-B2BDF7CEB9F4@FreeBSD.org> In-Reply-To: <Z4bJihbQUmD0cjpN@cell.glebi.us> References: <0DC91E3B-DDB4-43ED-866E-3DA02BBA1241@FreeBSD.org> <Z4bJihbQUmD0cjpN@cell.glebi.us>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > On Jan 15, 2025, at 4:31 AM, Gleb Smirnoff <glebius@freebsd.org> wrote: > > On Tue, Jan 14, 2025 at 07:25:26PM +0800, Zhenlei Huang wrote: > Z> I just fixed one long standing bug of sppp(4) [1]. During the testing I found ng_sppp(4) depends on this module. Unfortunately sppp(4) is only enabled on i386 and amd64 by default but ng_sppp(4) is enabled on all architectures. So on architectures other than i386 and amd64 `kldload ng_sppp` will never succeed. > Z> > Z> I suppose sppp(4) is rarely used nowadays so I'm planing to conditionally build ng_sppp(4) only on i386 and amd64. Is there still real usage of sppp(4) on other architectures ? > Z> > Z> 1. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173002 > > I would claim there is no usage of neither sppp(4) nor ng_sppp(4) on any > architecture in a very long term. Last time I run this kind of network framing > in 2004 and in that times the right way to do it was either pure negraph(4) > graph based on ng_cisco(4) or ports/net/mpd + ng_ppp(4). > > Don't waste your time on this code. This is a quick simple fix. Committed as https://cgit.freebsd.org/src/commit/?h=stable/13&id=29f77be0d844aa7e9b26fed8b550e12ad504b4d2 <https://cgit.freebsd.org/src/commit/?h=stable/13&id=29f77be0d844aa7e9b26fed8b550e12ad504b4d2>; . > > -- > Gleb Smirnoff [-- Attachment #2 --] <html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 15, 2025, at 4:31 AM, Gleb Smirnoff <<a href="mailto:glebius@freebsd.org" class="">glebius@freebsd.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Tue, Jan 14, 2025 at 07:25:26PM +0800, Zhenlei Huang wrote:<br class="">Z> I just fixed one long standing bug of sppp(4) [1]. During the testing I found ng_sppp(4) depends on this module. Unfortunately sppp(4) is only enabled on i386 and amd64 by default but ng_sppp(4) is enabled on all architectures. So on architectures other than i386 and amd64 `kldload ng_sppp` will never succeed.<br class="">Z> <br class="">Z> I suppose sppp(4) is rarely used nowadays so I'm planing to conditionally build ng_sppp(4) only on i386 and amd64. Is there still real usage of sppp(4) on other architectures ?<br class="">Z> <br class="">Z> 1. <a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173002" class="">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173002</a><br class=""><br class="">I would claim there is no usage of neither sppp(4) nor ng_sppp(4) on any<br class="">architecture in a very long term. Last time I run this kind of network framing<br class="">in 2004 and in that times the right way to do it was either pure negraph(4)<br class="">graph based on ng_cisco(4) or ports/net/mpd + ng_ppp(4).<br class=""><br class="">Don't waste your time on this code.<br class=""></div></div></blockquote><div><br class=""></div><div>This is a quick simple fix.</div><div>Committed as <a href="https://cgit.freebsd.org/src/commit/?h=stable/13&id=29f77be0d844aa7e9b26fed8b550e12ad504b4d2" class="">https://cgit.freebsd.org/src/commit/?h=stable/13&id=29f77be0d844aa7e9b26fed8b550e12ad504b4d2</a> .</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">-- <br class="">Gleb Smirnoff<br class=""></div></div></blockquote></div><div class=""><div><br class=""></div> </div> <br class=""></body></html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57B63ECF-F2A2-43FB-8814-B2BDF7CEB9F4>