Re: [PATCH] build: Fix errors of TCP_REPAIR_* undeclared

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 2 Sep 2025 10:54:35 +0800
Yumei Huang <yuhuang@redhat.com> wrote:

> Thank you Stefano for all the comments.  Sent v2 to address all the issues,
> just that..
> 
> On Tue, Sep 2, 2025 at 5:02 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> 
> > Thanks for the patch! A couple of comments, all minor:
> >
> > On Mon,  1 Sep 2025 17:45:10 +0800
> > Yumei Huang <yuhuang@redhat.com> wrote:
> >  
> > > Fix the following errors on systems with glibc < 2.29:  
> >
> > Before anything, it's customary to credit the original author of a
> > patch, even if it was (very) different. Something like:
> >
> > Based on an original patch by Dongsheng, fix ...
> >
> > and I think you should also Cc: them (they might want to test / comment
> > / review), you can fetch the contact from
> > https://bugs.passt.top/show_bug.cgi?id=121.
> >  
> > >
> > > tcp.c: In function ‘tcp_flow_repair_on’:
> > > tcp.c:2787:38: error: ‘TCP_REPAIR_ON’ undeclared (first use in this  
> > function); did you mean ‘TCP_REPAIR’?  
> > >   if ((rc = repair_set(c, conn->sock, TCP_REPAIR_ON)))
> > >                                       ^~~~~~~~~~~~~
> > >                                       TCP_REPAIR
> > > tcp.c:2787:38: note: each undeclared identifier is reported only once  
> > for each function it appears in  
> > > tcp.c: In function ‘tcp_flow_repair_off’:
> > > tcp.c:2807:38: error: ‘TCP_REPAIR_OFF’ undeclared (first use in this  
> > function); did you mean ‘TCP_REPAIR’?  
> > >   if ((rc = repair_set(c, conn->sock, TCP_REPAIR_OFF)))
> > >                                       ^~~~~~~~~~~~~~
> > >                                       TCP_REPAIR
> > > make: *** [Makefile:94: passt] Error 1
> > >
> > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>  
> >
> > Just before this tag, we typically add any references, always using the
> > "Link:" tag for simplicity.
> >
> > Many other projects use separate tags such as "Bug:", "Bugzilla:",
> > "Closes:" and so on, but we don't, so that it's a bit easier to
> > automate parsing, if needed. In this case that would be:
> >
> > Link: https://bugs.passt.top/show_bug.cgi?id=121
> >
> > and perhaps a Reported-by: tag would also be good to have, here.
> >  
> > > ---
> > >  linux_dep.h    | 6 ++++++
> > >  passt-repair.c | 1 +
> > >  2 files changed, 7 insertions(+)
> > >
> > > diff --git a/linux_dep.h b/linux_dep.h
> > > index 240f50a..c200444 100644
> > > --- a/linux_dep.h
> > > +++ b/linux_dep.h
> > > @@ -135,6 +135,12 @@ struct tcp_info_linux {
> > >  #define CLOSE_RANGE_UNSHARE  (1U << 1)
> > >  #endif
> > >
> > > +#ifndef TCP_REPAIR_ON
> > > +#define TCP_REPAIR_ON           1
> > > +#define TCP_REPAIR_OFF          0
> > > +#define TCP_REPAIR_OFF_NO_WP    -1      /* Turn off without window  
> > probes */
> >
> > We use tabs for indentation, and a full tab is displayed as 8 characters
> > wide. For example:
> >
> > #define TCP_REPAIR_ON           1
> >                       ^^ two tabs here, so that TCP_REPAIR_OFF_NO_WP is
> >                       aligned too
> >
> > I did replace the spaces here with two tabs in v2,  and it shows aligned  
> in my editors both vim and vscode, but it seems it's not in gmail.
> Tried 'set tabstop=8' and removed 'set expandtab' in the .vimrc file, and
> got the same result. Not sure what's going wrong...

I'm not sure either, just mind that you shouldn't rely on the web
interface of Gmail because it won't show you emails / patches exactly
as they are. But v2 looks good to me, so I guess you fixed it. :)

Two more things:

1. look at two paragraph above this one, you'll see that quoting is not
   correct:

> > I did replace ...
> in my editors

it looks as if "I did replace ..." is from my reply, not from yours.
I've seen this issue with people using Gmail but as far as I understood
it's a known issue on Gmail side and they don't plan to fix it.

2. your reply contains an HTML version. While I configured passt mailing
   lists to be tolerant of that, I think that many upstream mailing
   lists (e.g. kernel lists) will just drop your message altogether if
   it contains an HTML part.

In the end, I would suggest you use an email client instead, which
makes it so much easier to work with code. I use claws-mail, other
popular options include Thunderbird, Sylpheed, mutt.

Maybe it can all be fixed with Gmail configurations, I'm not sure, but
I've seen people struggling quite a bit before deciding to use an email
client (at least for lists and patches).

-- 
Stefano