Re: trpt(8) to be decomissioned
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
Re: trpt(8) to be decomissioned
> On 5. Nov 2022, at 01:54, Cy Schubert wrote: > > In message , Gleb Smirnoff writes: >> Max, >> >> the reason I want to retire it is not that it consumes 40 Kb >> in the repository. The reason is that knows kernel structures, >> and fails to compile after changes to them. So the tool that >> nobody uses requires special care when working on TCP. The >> kernel headers disclose the structures for trpt (with some >> protection with _WANT_TCPCB, though) and some software from >> ports (not calling names!) would start use them too. Now a >> kernel developer needs to care not only about trpt, but >> about this software, too. > > I recall when Bryan Cantrill came to one of the local hotels here to > announce Solaris 9, I remember him saying that Solaris truss was now an app > that called DTrace functions. If people feel the need for trpt-like > utility, would it be an idea to write it using DTrace calls? Could it be a > GSoC project? It would be kind of neat for a co-op student or someone to > get their feet wet with systems programming. > > I typically use DTrace when snooping around looking for that proverbial > needle in a haystack. And TCPDEBUG seems to be one of those things that > DTrace was designed to replace. > > It would be a good project to have a still in school upcoming developer to > work on. That plan is to use BBLog as an replacement. Best regards Michael > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 > > > > >
Re: trpt(8) to be decomissioned
In message , Gleb Smirnoff writes: > Max, > > the reason I want to retire it is not that it consumes 40 Kb > in the repository. The reason is that knows kernel structures, > and fails to compile after changes to them. So the tool that > nobody uses requires special care when working on TCP. The > kernel headers disclose the structures for trpt (with some > protection with _WANT_TCPCB, though) and some software from > ports (not calling names!) would start use them too. Now a > kernel developer needs to care not only about trpt, but > about this software, too. I recall when Bryan Cantrill came to one of the local hotels here to announce Solaris 9, I remember him saying that Solaris truss was now an app that called DTrace functions. If people feel the need for trpt-like utility, would it be an idea to write it using DTrace calls? Could it be a GSoC project? It would be kind of neat for a co-op student or someone to get their feet wet with systems programming. I typically use DTrace when snooping around looking for that proverbial needle in a haystack. And TCPDEBUG seems to be one of those things that DTrace was designed to replace. It would be a good project to have a still in school upcoming developer to work on. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0
Re: trpt(8) to be decomissioned
On Fri, Nov 4, 2022 at 1:19 AM Max Baroi wrote: > I'm sorry if this is an inappropriate suggestion, but I think it would be > neat if there was a place in the ports hierarchy for retired programs like > trpt. Maybe a "historical" or "archival" directory for programs phased out > of from base, especially ones that are almost four decades old. > The nice thing about revision control software is that it will have a copy of this code forever. Warner
Re: trpt(8) to be decomissioned
On 2022-11-04 09:40, Gleb Smirnoff wrote: Max, the reason I want to retire it is not that it consumes 40 Kb in the repository. The reason is that knows kernel structures, and fails to compile after changes to them. So the tool that nobody uses requires special care when working on TCP. The kernel headers disclose the structures for trpt (with some protection with _WANT_TCPCB, though) and some software from ports (not calling names!) would start use them too. Now a kernel developer needs to care not only about trpt, but about this software, too. On the kernel side there is also TCPDEBUG code that needs to be kept compilable, while apparently nobody uses it. While I really hate hearing that small utils (almost elegant in their simplicity) that have worked perfectly well for a great many years must be kicked to the curb. I guess I can see your point. However I think TCPDEBUG affects a great deal more that trpt(8). I hope your not implying that it should go as well. On Fri, Nov 04, 2022 at 07:19:19AM +, Max Baroi wrote: M> I'm sorry if this is an inappropriate suggestion, but I think it would be neat if there was a place in the ports hierarchy for retired programs like trpt. Maybe a "historical" or "archival" directory for programs phased out of from base, especially ones that are almost four decades old. M> M> -Max M> M> Nov 3, 2022 11:04:07 PM Mike Karels : M> M> > On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote: M> > M> >> Hi, M> >> M> >> trpt(8) is utility to pull TCP debugging data from the kernel M> >> in 4.2BSD. We still have it in the base, with corresponding M> >> TCPDEBUG option in the kernel and SO_DEBUG socket option. M> >> M> >> At the same time we have much more powerful debugging facilities M> >> for TCP, e.g. the Dtrace probing, the TCP black box logging and M> >> siftr. These are the tools that modern developers use. modern developer(s): those whom create things that scratch their itch, without looking hard enough to see that something else was already available. ;-) M> >> M> >> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@. M> >> None of them new what trpt(8) is :) Looks like a good justification M> >> to me. M> > M> > I have used trpt, but not for many years. It was done before tcpdump M> > as well. Its time has long since gone. M> > M> > Mike M> >> -- M> >> Gleb Smirnoff M> M> --chris 0xBDE49540.asc Description: application/pgp-keys
Re: trpt(8) to be decomissioned
Gleb, Thank you for the response. I rescind my suggestion. -Max On 11/4/2022 9:40 AM, Gleb Smirnoff wrote: Max, the reason I want to retire it is not that it consumes 40 Kb in the repository. The reason is that knows kernel structures, and fails to compile after changes to them. So the tool that nobody uses requires special care when working on TCP. The kernel headers disclose the structures for trpt (with some protection with _WANT_TCPCB, though) and some software from ports (not calling names!) would start use them too. Now a kernel developer needs to care not only about trpt, but about this software, too. On the kernel side there is also TCPDEBUG code that needs to be kept compilable, while apparently nobody uses it. On Fri, Nov 04, 2022 at 07:19:19AM +, Max Baroi wrote: M> I'm sorry if this is an inappropriate suggestion, but I think it would be neat if there was a place in the ports hierarchy for retired programs like trpt. Maybe a "historical" or "archival" directory for programs phased out of from base, especially ones that are almost four decades old. M> M> -Max M> M> Nov 3, 2022 11:04:07 PM Mike Karels : M> M> > On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote: M> > M> >> Hi, M> >> M> >> trpt(8) is utility to pull TCP debugging data from the kernel M> >> in 4.2BSD. We still have it in the base, with corresponding M> >> TCPDEBUG option in the kernel and SO_DEBUG socket option. M> >> M> >> At the same time we have much more powerful debugging facilities M> >> for TCP, e.g. the Dtrace probing, the TCP black box logging and M> >> siftr. These are the tools that modern developers use. M> >> M> >> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@. M> >> None of them new what trpt(8) is :) Looks like a good justification M> >> to me. M> > M> > I have used trpt, but not for many years. It was done before tcpdump M> > as well. Its time has long since gone. M> > M> > Mike M> >> -- M> >> Gleb Smirnoff M> M>
Re: trpt(8) to be decomissioned
Max, the reason I want to retire it is not that it consumes 40 Kb in the repository. The reason is that knows kernel structures, and fails to compile after changes to them. So the tool that nobody uses requires special care when working on TCP. The kernel headers disclose the structures for trpt (with some protection with _WANT_TCPCB, though) and some software from ports (not calling names!) would start use them too. Now a kernel developer needs to care not only about trpt, but about this software, too. On the kernel side there is also TCPDEBUG code that needs to be kept compilable, while apparently nobody uses it. On Fri, Nov 04, 2022 at 07:19:19AM +, Max Baroi wrote: M> I'm sorry if this is an inappropriate suggestion, but I think it would be neat if there was a place in the ports hierarchy for retired programs like trpt. Maybe a "historical" or "archival" directory for programs phased out of from base, especially ones that are almost four decades old. M> M> -Max M> M> Nov 3, 2022 11:04:07 PM Mike Karels : M> M> > On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote: M> > M> >> Hi, M> >> M> >> trpt(8) is utility to pull TCP debugging data from the kernel M> >> in 4.2BSD. We still have it in the base, with corresponding M> >> TCPDEBUG option in the kernel and SO_DEBUG socket option. M> >> M> >> At the same time we have much more powerful debugging facilities M> >> for TCP, e.g. the Dtrace probing, the TCP black box logging and M> >> siftr. These are the tools that modern developers use. M> >> M> >> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@. M> >> None of them new what trpt(8) is :) Looks like a good justification M> >> to me. M> > M> > I have used trpt, but not for many years. It was done before tcpdump M> > as well. Its time has long since gone. M> > M> > Mike M> >> -- M> >> Gleb Smirnoff M> M> -- Gleb Smirnoff
Re: trpt(8) to be decomissioned
I'm sorry if this is an inappropriate suggestion, but I think it would be neat if there was a place in the ports hierarchy for retired programs like trpt. Maybe a "historical" or "archival" directory for programs phased out of from base, especially ones that are almost four decades old. -Max Nov 3, 2022 11:04:07 PM Mike Karels : > On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote: > >> Hi, >> >> trpt(8) is utility to pull TCP debugging data from the kernel >> in 4.2BSD. We still have it in the base, with corresponding >> TCPDEBUG option in the kernel and SO_DEBUG socket option. >> >> At the same time we have much more powerful debugging facilities >> for TCP, e.g. the Dtrace probing, the TCP black box logging and >> siftr. These are the tools that modern developers use. >> >> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@. >> None of them new what trpt(8) is :) Looks like a good justification >> to me. > > I have used trpt, but not for many years. It was done before tcpdump > as well. Its time has long since gone. > > Mike >> -- >> Gleb Smirnoff
Re: trpt(8) to be decomissioned
On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote: > Hi, > > trpt(8) is utility to pull TCP debugging data from the kernel > in 4.2BSD. We still have it in the base, with corresponding > TCPDEBUG option in the kernel and SO_DEBUG socket option. > > At the same time we have much more powerful debugging facilities > for TCP, e.g. the Dtrace probing, the TCP black box logging and > siftr. These are the tools that modern developers use. > > Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@. > None of them new what trpt(8) is :) Looks like a good justification > to me. I have used trpt, but not for many years. It was done before tcpdump as well. Its time has long since gone. Mike > -- > Gleb Smirnoff
