From nobody Fri Dec 29 17:09:07 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1sL873Mqz54WF6 for ; Fri, 29 Dec 2023 17:09:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1sL832hsz4YCL for ; Fri, 29 Dec 2023 17:09:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-40d60ad5f0bso24508255e9.0 for ; Fri, 29 Dec 2023 09:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1703869758; x=1704474558; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rQrF6UsxLMUvIyeyPIrhElQPwAJGBfb6Hv6l/Co8g+8=; b=Seo+WGAE7ysVwevseHP52qiKtoJN8QcXodCNCm7j7UujLGZPQsPupo0yZt1pJFYQam 0hAM3BNRpOAmS2Lrth6tN3P8QCy8aF9sg8yQr3jdim8x0M65VYLMvU1XNaqt5SDlYH52 GpRCzAij0nSMaPxpSpodNfmuYfPzvy54lqpMekEN93HI86dk6byllEgAO3riH4WvO0/X BjP3NXJ5+yTrMsbWU8gzYWXE70TVEEt+K2ed1BKBrz+xyWcxiiyHwooM2O8OnQiNhsO4 iHYL/zbgGl+EpdKbnJF5v8aERCUYQ/+bEATUa0Ul+vYRz5qluDJlEllC2HHJEI2+GgDo S3SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703869758; x=1704474558; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rQrF6UsxLMUvIyeyPIrhElQPwAJGBfb6Hv6l/Co8g+8=; b=ak+5BY3/Y4Wwue0Ud7fsmgfO2g8zS60fx7G+Mk5nUO68SZTteWNvGMbP/mShdntSo8 NaiS2qvxy+pLuNG6RCzbq/+C6MPmo29R3pY+5KmrP+f+7IEmJSPiEcIFa8bkpfWHbHDO i2fJuXRKHATkNqlf13Oz4EbcsHBFwMhZ/0EhQyDSoTpNGh9YJSpyuROrUd7EbHembcaH SxklCUPtk/+vNjmXm2g60RTq2n1PuxpQCLzlgSVaqK8/WyhjqG9OcyvH1MHiWL7a61k8 P3TnRHc091v+iSIMTm9AGaj2t7BvhbKRzuPF5gy1VILtSKIAIf9bV/h8w4qOiUbhtEIB MGhw== X-Gm-Message-State: AOJu0YyZ8mto5FWzQ3iF/oEKqQCiA52TXSI33rIjx8uOeEMiOmpOWUsE TewMeSe1i1Qoo2PrMRSaWYvYVR1d6Y0W+UxszNQA3o7BJ2o7dg== X-Google-Smtp-Source: AGHT+IFzou5tLiJVXuQQL8sQG4xr3T+I6sjtrQWIF5djb7qQsGVzVrGEkCyxuPHFRD4zTCNNtNJY9xFryhfQ3lPdv6o= X-Received: by 2002:a05:600c:283:b0:40d:1d7f:a810 with SMTP id 3-20020a05600c028300b0040d1d7fa810mr7560251wmk.102.1703869758039; Fri, 29 Dec 2023 09:09:18 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <9EE91B0D-6CFB-464E-AB9C-3A15D77D55FB@freebsd.org> In-Reply-To: From: Warner Losh Date: Fri, 29 Dec 2023 10:09:07 -0700 Message-ID: Subject: Re: devel/nspr: Fails to build on 1500008 5f71f9636efa To: Michael Tuexen Cc: Konstantin Belousov , Dimitry Andric , Nuno Teixeira , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000ac00cd060da917d5" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1sL832hsz4YCL --000000000000ac00cd060da917d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 29, 2023, 6:52=E2=80=AFAM wrote: > > > > On Dec 29, 2023, at 14:43, tuexen@freebsd.org wrote: > > > >> On Dec 29, 2023, at 14:07, Konstantin Belousov > wrote: > >> > >> On Fri, Dec 29, 2023 at 01:50:34PM +0100, Dimitry Andric wrote: > >>> The problem is really that our kernel headers (those under sys/) > require C99. The only thing that > https://cgit.freebsd.org/src/commit/?id=3Da8b70cf26030d68631200619bd1b0ad= 35b34b6b8 > did was move two static inline functions from sys/netinet/tcp_var.h to > sys/netinet/tcp.h, and it looks like the former header is never directly > included by ports. The latter is, so those ports should be switched to C9= 9, > or the sys/netinet/tcp.h header should be fixed to use __inline instead. > >>> > >> netinet/tcp.h is required by POSIX, and as far as we support > applications > >> using C89, it must stay C89 compatible. > >> > >> But why userspace would need these newish accessors at all? IMO at > least > > TCP is now using flags that are not contained in the th_flags field > anymore, > > but also use the th_x2 field. > > > > People were assuming that all flags are in th_flags and th_x2 is not > used and > > used it for internal processing. This was causing problems. > > > > Using the accessor functions hides the split between th_flags and th_x2= . > > See, for example, > > > https://cgit.FreeBSD.org/src/commit/?id=3Da8b70cf26030d68631200619bd1b0ad= 35b34b6b8 > < > https://cgit.freebsd.org/src/commit/?id=3Da8b70cf26030d68631200619bd1b0ad= 35b34b6b8 > > > >> for userspace they do not add any value except additional namespace > pollution. > >> They should be hidden under #ifdef _KERNEL. > > That might be possible. A kernel build with this completes. Haven't > checked a > > buildlworld. Will report when its done. > Thinking about it: since we expose the TCP flags to the world, we should > also expose the accessors related to it. > Yea. __inline is the way to go. I should add this test to the includes test we already run at buildworld time... Warner Best regards > Michael > > > > Best regards > > Michael > >> > >>> -Dimitry > >>> > >>>> On 29 Dec 2023, at 13:30, Nuno Teixeira wrote: > >>>> > >>>> (...) > >>>> -ansi =3D=3D Same as -std=3Dc89 > >>>> > >>>> So it seems correct to remove it when -std=3Dc99 is used. > >>>> > >>>> Nuno Teixeira escreveu no dia sexta, > 29/12/2023 =C3=A0(s) 12:03: > >>>> > >>>> > >>>> > >>>> I think we have two options: > >>>> 1. Build the ports with a C version of at least C99. > >>>> > >>>> - Adding USE_CSTD=3Dc99 > >>>> - Removing -ansi: > >>>> --- configure.orig 2023-12-29 11:54:11 UTC > >>>> +++ configure > >>>> - CFLAGS=3D"$CFLAGS $(DSO_CFLAGS) -ansi -Wall" > >>>> + CFLAGS=3D"$CFLAGS $(DSO_CFLAGS) -Wall" > >>>> > >>>> Fix build. > >>>> > >>>> Notes: > >>>> > >>>> Adding USE_CSTD=3Dc99 doesn't fix build by itself like we seen on so= me > ports that were fixed by it. > >>>> > >>>> Something have changed from current 1500007 to 1500008. > >>>> > >>>> 2. Remove the inline from tcp_[gs]et_flags(). > >>>> > >>>> Best regards > >>>> Michael > >>>>> -- > >>>>> Nuno Teixeira > >>>>> FreeBSD Committer (ports) > >>>> > >>>> > >>>> > >>>> -- > >>>> Nuno Teixeira > >>>> FreeBSD Committer (ports) > >>>> > >>>> > >>>> -- > >>>> Nuno Teixeira > >>>> FreeBSD Committer (ports) > >>> > >>> > > > > > > > --000000000000ac00cd060da917d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 29, 2023, 6:52=E2=80=AFAM <tuexen@freebsd.org> wrote:


> On Dec 29, 2023, at 14:43, tuexen@freebsd.org wrote:
>
>> On Dec 29, 2023, at 14:07, Konstantin Belousov <kostikbel@gmai= l.com> wrote:
>>
>> On Fri, Dec 29, 2023 at 01:50:34PM +0100, Dimitry Andric wrote: >>> The problem is really that our kernel headers (those under sys= /) require C99. The only thing that https://cgit.freebsd.org/src/commit/?id=3Da8b7= 0cf26030d68631200619bd1b0ad35b34b6b8 did was move two static inline fun= ctions from sys/netinet/tcp_var.h to sys/netinet/tcp.h, and it looks like t= he former header is never directly included by ports. The latter is, so tho= se ports should be switched to C99, or the sys/netinet/tcp.h header should = be fixed to use __inline instead.
>>>
>> netinet/tcp.h is required by POSIX, and as far as we support appli= cations
>> using C89, it must stay C89 compatible.
>>
>> But why userspace would need these newish accessors at all?=C2=A0 = IMO at least
> TCP is now using flags that are not contained in the th_flags field an= ymore,
> but also use the th_x2 field.
>
> People were assuming that all flags are in th_flags and th_x2 is not u= sed and
> used it for internal processing. This was causing problems.
>
> Using the accessor functions hides the split between th_flags and th_x= 2.
> See, for example,
> ht= tps://cgit.FreeBSD.org/src/commit/?id=3Da8b70cf26030d68631200619bd1b0ad35b3= 4b6b8 <https://cgit.freebsd.org/src/commit/?id=3Da8b70cf26030d68631200619bd= 1b0ad35b34b6b8>
>> for userspace they do not add any value except additional namespac= e pollution.
>> They should be hidden under #ifdef _KERNEL.
> That might be possible. A kernel build with this completes. Haven'= t checked a
> buildlworld. Will report when its done.
Thinking about it: since we expose the TCP flags to the world, we should also expose the accessors related to it.

Yea. __inline is the way to go.

I should add this test to t= he includes test we already run at buildworld time...

Warner

Best regards
Michael
>
> Best regards
> Michael
>>
>>> -Dimitry
>>>
>>>> On 29 Dec 2023, at 13:30, Nuno Teixeira <eduardo@freeb= sd.org> wrote:
>>>>
>>>> (...)
>>>> -ansi =3D=3D Same as -std=3Dc89
>>>>
>>>> So it seems correct to remove it when -std=3Dc99 is used.<= br> >>>>
>>>> Nuno Teixeira <eduardo@freebsd.org> escreveu no= dia sexta, 29/12/2023 =C3=A0(s) 12:03:
>>>>
>>>>
>>>>
>>>> I think we have two options:
>>>> 1. Build the ports with a C version of at least C99.
>>>>
>>>> - Adding USE_CSTD=3Dc99
>>>> - Removing -ansi:
>>>> --- configure.orig=C2=A0 =C2=A0 =C2=A02023-12-29 11:54:11 = UTC
>>>> +++ configure
>>>> -=C2=A0 =C2=A0 CFLAGS=3D"$CFLAGS $(DSO_CFLAGS) -ansi = -Wall"
>>>> +=C2=A0 =C2=A0 CFLAGS=3D"$CFLAGS $(DSO_CFLAGS) -Wall&= quot;
>>>>
>>>> Fix build.
>>>>
>>>> Notes:
>>>>
>>>> Adding USE_CSTD=3Dc99 doesn't fix build by itself like= we seen on some ports that were fixed by it.
>>>>
>>>> Something have changed from current 1500007 to 1500008. >>>>
>>>> 2. Remove the inline from tcp_[gs]et_flags().
>>>>
>>>> Best regards
>>>> Michael
>>>>> --
>>>>> Nuno Teixeira
>>>>> FreeBSD Committer (ports)
>>>>
>>>>
>>>>
>>>> --
>>>> Nuno Teixeira
>>>> FreeBSD Committer (ports)
>>>>
>>>>
>>>> --
>>>> Nuno Teixeira
>>>> FreeBSD Committer (ports)
>>>
>>>
>
>


--000000000000ac00cd060da917d5--