Date: Sun, 6 Nov 2022 12:16:47 -0800 From: Gleb Smirnoff <glebius@freebsd.org> To: Chris <bsd-lists@bsdforge.com> Cc: Max Baroi <max@baroi.com>, Mike Karels <mike@karels.net>, current@freebsd.org Subject: Re: trpt(8) to be decomissioned Message-ID: <Y2gWL38zfT76bL1m@FreeBSD.org> In-Reply-To: <c74aeef3e274c576e3ae9899b292be1b@bsdforge.com> References: <Y2SLfz19F6JoC6av@FreeBSD.org> <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net> <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com> <Y2VAdN%2BDC6jy%2BL4d@FreeBSD.org> <c74aeef3e274c576e3ae9899b292be1b@bsdforge.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris, On Fri, Nov 04, 2022 at 10:35:17AM -0700, Chris wrote: C> > the reason I want to retire it is not that it consumes 40 Kb C> > in the repository. The reason is that knows kernel structures, C> > and fails to compile after changes to them. So the tool that C> > nobody uses requires special care when working on TCP. The C> > kernel headers disclose the structures for trpt (with some C> > protection with _WANT_TCPCB, though) and some software from C> > ports (not calling names!) would start use them too. Now a C> > kernel developer needs to care not only about trpt, but C> > about this software, too. C> > C> > On the kernel side there is also TCPDEBUG code that needs C> > to be kept compilable, while apparently nobody uses it. C> While I really hate hearing that small utils C> (almost elegant in their simplicity) that have worked perfectly C> well for a great many years must be kicked to the curb. I guess C> I can see your point. However I think TCPDEBUG affects a great C> deal more that trpt(8). I hope your not implying that it should C> go as well. I'd like to hear use scenarios of TCPDEBUG without trpt. What does it provide that other logging facilities (BB, DTrace) doesn't? -- Gleb Smirnoff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Y2gWL38zfT76bL1m>