Re: git: 022ca2fc7fe0 - main - Add aio_writev and aio_readv

2021-01-02 Thread Jessica Clarke
On 3 Jan 2021, at 02:59, Alan Somers  wrote:
> diff --git a/sys/kern/syscalls.master b/sys/kern/syscalls.master
> index b7ea5e939635..aaa0a1277461 100644
> --- a/sys/kern/syscalls.master
> +++ b/sys/kern/syscalls.master
> @@ -1477,7 +1477,17 @@
>   _In_opt_ struct sigevent *sig
>   );
>   }
> -258-271  AUE_NULLUNIMPL  nosys
> +258  AUE_AIO_WRITEV  STD {
> + int aio_writev(
> + _Inout_ struct aiocb *aiocbp
> + );
> + }
> +259  AUE_AIO_READV   STD {
> + int aio_readv(
> + _Inout_ struct aiocb *aiocbp
> + );
> + }
> +260-271  AUE_NULLUNIMPL  nosys
> 272   AUE_O_GETDENTS  COMPAT11 {
>   int getdents(
>   int fd,

Should these not be added to the end?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 9c6954329a92 - main - bsd.compiler.mk: Detect distribution-provided GCC when executed as cc

2021-02-09 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=9c6954329a9285547881ddd60e393b7c55ed30c4

commit 9c6954329a9285547881ddd60e393b7c55ed30c4
Author: Jessica Clarke 
AuthorDate: 2021-02-09 21:40:24 +
Commit: Jessica Clarke 
CommitDate: 2021-02-09 21:40:24 +

bsd.compiler.mk: Detect distribution-provided GCC when executed as cc

Clang always prints "clang $VERSION" regardless of the name used to
execute it, whereas GCC prints "$progname $VERSION", meaning if CC is
set to cc and cc is GCC it will print "cc $VERSION". We are able to
detect some of those cases since it then prints "($PKGVERSION)", where
the default is "GCC", but many distributions override that to print
their name and the package version number (e.g. "Debian 10.2.1-6"), so
nothing tells us it's GCC other than the fact that it's not Clang (and
that there's an FSF copyright disclaimer).

However, GCC's -v option will always print "gcc version $VERSION", so
fall back on using that to detect GCC. Whilst Clang also supports this
option, we should never get here, so Clang handling is not added.

Reviewed by:brooks, emaste, arichardson
Differential Revision:  https://reviews.freebsd.org/D28315
---
 share/mk/bsd.compiler.mk | 9 +
 1 file changed, 9 insertions(+)

diff --git a/share/mk/bsd.compiler.mk b/share/mk/bsd.compiler.mk
index 8253669fe279..fa8e6c44a17e 100644
--- a/share/mk/bsd.compiler.mk
+++ b/share/mk/bsd.compiler.mk
@@ -187,7 +187,16 @@ ${X_}COMPILER_TYPE:=   gcc
 . elif ${_v:Mclang} || ${_v:M(clang-*.*.*)}
 ${X_}COMPILER_TYPE:=   clang
 . else
+# With GCC, cc --version prints "cc $VERSION ($PKGVERSION)", so if a
+# distribution overrides the default GCC PKGVERSION it is not identified.
+# However, its -v output always says "gcc version" in it, so fall back on that.
+_gcc_version!= ${${cc}:N${CCACHE_BIN}} -v 2>&1 | grep "gcc version"
+.  if !empty(_gcc_version)
+${X_}COMPILER_TYPE:=   gcc
+.  else
 .error Unable to determine compiler type for ${cc}=${${cc}}.  Consider setting 
${X_}COMPILER_TYPE.
+.  endif
+.undef _gcc_version
 . endif
 .endif
 .if !defined(${X_}COMPILER_VERSION)
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 01d07b03ef2b - main - localedef: Fix bootstrapping on Ubuntu 16.04

2021-02-10 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=01d07b03ef2b59e70a25cfc4d9e438a7331c5926

commit 01d07b03ef2b59e70a25cfc4d9e438a7331c5926
Author: Jessica Clarke 
AuthorDate: 2021-02-10 16:41:35 +
Commit: Jessica Clarke 
CommitDate: 2021-02-10 16:41:35 +

localedef: Fix bootstrapping on Ubuntu 16.04

Glibc's stdlib.h defines various prototypes for GNU extensions that take
a locale_t. Newer versions use locale_t directly and include an internal
bits/types/locale_t.h in order to get its definition, but older versions
include xlocale.h for that, for which our bootstrap version is empty.
Moreover it expects to use the glibc-specific __locale_t type. Thus,
provide dummy definitions of both types in order to ensure the
prototypes don't give any errors, and guard against the header being
inadvertently included between the bootstrapping namespace.h and
un-namespace.h, where locale_t is #define'd.

This header is not used when bootstrapping on FreeBSD and exists solely
to stub out glibc's, so this should have no impact on FreeBSD hosts.

Reviewed by:arichardson, emaste (comment only)
Differential Revision:  https://reviews.freebsd.org/D28317
---
 usr.bin/localedef/bootstrap/xlocale.h | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/usr.bin/localedef/bootstrap/xlocale.h 
b/usr.bin/localedef/bootstrap/xlocale.h
index 67d1cc4116c6..05629a32f4e3 100644
--- a/usr.bin/localedef/bootstrap/xlocale.h
+++ b/usr.bin/localedef/bootstrap/xlocale.h
@@ -35,8 +35,21 @@
  *
  * $FreeBSD$
  */
+
+#pragma once
+
 /*
- * This header only exists to avoid pulling in the host xlocale.h from
- * the libc-internal headers. This is required since newer Linux GLibc no
- * longer includes xlocale.h and older versions include an incompatible header.
+ * This header only exists to avoid pulling in the host xlocale.h from the
+ * libc-internal headers. New versions of glibc include bits/types/locale.h
+ * from stdlib.h and so get their own locale_t (and don't provide xlocale.h),
+ * but older versions include xlocale.h and expect to have a __locale_t. Thus
+ * we provide dummy definitions of both so the (unused) prototypes don't give
+ * errors.
  */
+
+#ifdef locale_t
+#error "Dummy xlocale.h included inside bootstrapping namespace context"
+#endif
+
+typedefstruct __dummy_host_locale  *__locale_t;
+typedef__locale_t  locale_t;
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 24fd63e0970f - main - mips: Don't set __NO_TLS to disable some uses of TLS.

2021-02-18 Thread Jessica Clarke
On 18 Feb 2021, at 20:52, Konstantin Belousov  wrote:
> On Wed, Feb 17, 2021 at 04:48:22PM -0800, John Baldwin wrote:
>> On 2/17/21 4:35 PM, John Baldwin wrote:
>>> The branch main has been updated by jhb:
>>> 
>>> URL: 
>>> https://cgit.FreeBSD.org/src/commit/?id=24fd63e0970f91189dd2acde987bd2e4c8c04a50
>>> 
>>> commit 24fd63e0970f91189dd2acde987bd2e4c8c04a50
>>> Author: John Baldwin 
>>> AuthorDate: 2021-02-18 00:34:23 +
>>> Commit: John Baldwin 
>>> CommitDate: 2021-02-18 00:34:23 +
>>> 
>>> mips: Don't set __NO_TLS to disable some uses of TLS.
>>> __NO_TLS was originally added to disable use of _Thread in the locale
>>> code in libc in 82dd5016bd749d1d9e1531bd1703aebeecceab34.  At the time
>>> libc did not support TLS on MIPS (I believe), but TLS support was
>>> added to libc (at least _set_tp.c) for MIPS about a month after
>>> __NO_TLS was added, but __NO_TLS was still left around.
>>> Reviewed by:imp
>>> Sponsored by:   DARPA
>>> Differential Revision:  https://reviews.freebsd.org/D28713
>>> ---
>>>  sys/sys/cdefs.h | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>> 
>>> diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h
>>> index 64f26480a2f5..ff18911f6acf 100644
>>> --- a/sys/sys/cdefs.h
>>> +++ b/sys/sys/cdefs.h
>>> @@ -768,8 +768,7 @@
>>>  #endif
>>>  #endif /* __STDC_WANT_LIB_EXT1__ */
>>> -#if defined(__mips) || \
>>> -(defined(__powerpc64__) && (!defined(_CALL_ELF) || _CALL_ELF == 1))
>>> +#if defined(__powerpc64__) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
>>>  #define__NO_TLS 1
>>>  #endif
>> 
>> It would be really nice to kill __NO_TLS entirely.  There is at least one
>> unconditional use of _Thread_local (sorry, should have used that instead
>> of _Thread above) in libc in stdlib/cxa_thread_atexit_impl.c, so it seems
>> highly unlikely that TLS is actually broken on any of our platforms as the
>> libc build would have been broken instead.
> 
> There is a difference between compile and runtime.  The mentioned libc
> use in cxa_thread_atexit_impl.c is to support some (I believe) rarely
> used C++ feature of thread-local storage with destructors, so it might
> be simply not observed often.  OTOH, locale functions infect almost
> everything string-related in libc, so the breakage would be quite
> visible.

It's also used in jemalloc for tsd_initialized which is a rather key
variable, so if TLS is broken you won't get very far in userspace
(source: I had to debug implementing it for CHERI-MIPS), well before
you even think about getting to locale functions.

> But, I wonder, what does CALL_ELF mean?  Is it for old 64bit PowerPC ABI,
> that was abandoned with the switch to ELFv2?

Yes, _CALL_ELF == 2 for ELFv2. I highly doubt the defines were needed
for the ELFv1 ABI, but they're especially redundant now. Presumably
David's original fixed commit[1] added powerpc64 to that list because
TLS wasn't yet supported in LLVM; that happened later in 2012 and our
wiki changed it to being implemented in December 2012[2]. So I suspect
it should have been deleted 8 years ago.

Jess

[1] b0968176b3a821598a31de6698e01931d1417584
[2] 
https://wiki.freebsd.org/action/diff/BuildingFreeBSDWithClang?action=diff&rev1=340&rev2=341

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 24fd63e0970f - main - mips: Don't set __NO_TLS to disable some uses of TLS.

2021-02-18 Thread Jessica Clarke
On 18 Feb 2021, at 23:57, Brandon Bergren  wrote:
> On Thu, Feb 18, 2021, at 3:07 PM, Jessica Clarke wrote:
>>> But, I wonder, what does CALL_ELF mean?  Is it for old 64bit PowerPC ABI,
>>> that was abandoned with the switch to ELFv2?
>> 
>> Yes, _CALL_ELF == 2 for ELFv2. I highly doubt the defines were needed
>> for the ELFv1 ABI, but they're especially redundant now. Presumably
>> David's original fixed commit[1] added powerpc64 to that list because
>> TLS wasn't yet supported in LLVM; that happened later in 2012 and our
>> wiki changed it to being implemented in December 2012[2]. So I suspect
>> it should have been deleted 8 years ago.
> 
> FreeBSD 13 will be the first ELFv2 release. FreeBSD 12 and below are ELFv1.
> 
> The reason for the line was to avoid breaking things during the development 
> period for ELFv2. Switching TLS on was one of the things I did at the same 
> time as the official ELFv2 transition. See 
> 2db975b0eb0f3378a39d63eeabe4e3617f4557f0.
> 
> This is NOT an 8 year old change, but I believe it can go away in HEAD as 
> long as the change isn't MFC'd to 12 or earlier.

But TLS isn't broken for ELFv1? Otherwise jemalloc would die in a fire
and nothing would ever work. TLS should have been working for ELFv1 for
many years by this point.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 24fd63e0970f - main - mips: Don't set __NO_TLS to disable some uses of TLS.

2021-02-18 Thread Jessica Clarke
On 19 Feb 2021, at 00:03, Brandon Bergren  wrote:
> On Thu, Feb 18, 2021, at 6:00 PM, Jessica Clarke wrote:
>> 
>> But TLS isn't broken for ELFv1? Otherwise jemalloc would die in a fire
>> and nothing would ever work. TLS should have been working for ELFv1 for
>> many years by this point.
>> 
>> Jess
> 
> It's not broken, but it's an ABI change to flip it back and forth. You get 
> RuneLocale errors in the middle of installworld if you try and install a 
> build with TLS enabled and have to do a double installworld to compensate for 
> the crashes.
> 
> For ABI stability reasons, it needs to stay on in 12 and below.

Ok, so the mistake was not deleting it 8 years ago and instead leaving
it around to become part of the ABI. The issue you're referring to
specifically is __getCurrentRuneLocale and _ThreadRuneLocale (the
latter doesn't exist for __NO_TLS, and the former changes between
static inline and extern)? __NO_TLS should have blocked powerpc64 (and
mips) from becoming tier 2 IMO, but we're stuck with it, so yeah, it's
a major ABI break (frustratingly tiny but breaks the core system
libraries) and thus can't be MFC'ed.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 963cf6cb0fd7 - main - uefi: Add riscv to historical details

2021-02-22 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=963cf6cb0fd7e8708c455ecf567fbc34fe2a7156

commit 963cf6cb0fd7e8708c455ecf567fbc34fe2a7156
Author: Jessica Clarke 
AuthorDate: 2021-02-22 22:27:00 +
Commit: Jessica Clarke 
CommitDate: 2021-02-22 22:27:00 +

uefi: Add riscv to historical details
---
 share/man/man8/uefi.8 | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/share/man/man8/uefi.8 b/share/man/man8/uefi.8
index 3ecfe05ac1c4..64bc30139f97 100644
--- a/share/man/man8/uefi.8
+++ b/share/man/man8/uefi.8
@@ -143,5 +143,7 @@ boot support for amd64 first appeared in
 .Fx 10.1 ;
 for arm64 in
 .Fx 11.0 ;
-and for armv6 and armv7 in
-.Fx 12.0 .
+for armv6 and armv7 in
+.Fx 12.0 ;
+and for riscv in
+.Fx 13.0 .
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 2a50a9de8340 - main - terminfo: add terminfo database

2021-02-26 Thread Jessica Clarke
> On 26 Feb 2021, at 17:30, Rodney W. Grimes  wrote:
> 
>> In message <202102251327.11pdr4ec083...@gitrepo.freebsd.org>, Baptiste 
>> Daroussi
>> n writes:
>>> The branch main has been updated by bapt:
>>> 
>>> URL: 
>>> https://cgit.FreeBSD.org/src/commit/?id=2a50a9de8340f08bd876e9e5993332ae
>>> 14376f80
>>> 
>>> commit 2a50a9de8340f08bd876e9e5993332ae14376f80
>>> Author: Baptiste Daroussin 
>>> AuthorDate: 2021-02-23 16:17:32 +
>>> Commit: Baptiste Daroussin 
>>> CommitDate: 2021-02-25 13:25:32 +
>>> 
>>>terminfo: add terminfo database
>>> 
>>>Tested by:  manu, jbeich
>>> ---
>>> share/Makefile  |  1 +
>>> share/terminfo/Makefile | 34 ++
>>> 2 files changed, 35 insertions(+)
>>> 
>>> diff --git a/share/Makefile b/share/Makefile
>>> index c4e12b05f7db..d6854b230ae5 100644
>>> --- a/share/Makefile
>>> +++ b/share/Makefile
>>> @@ -26,6 +26,7 @@ SUBDIR=   ${_colldef} \
>>> ${_syscons} \
>>> tabset \
>>> termcap \
>>> +   terminfo \
>>> ${_timedef} \
>>> ${_vt} \
>>> ${_zoneinfo}
>>> diff --git a/share/terminfo/Makefile b/share/terminfo/Makefile
>>> new file mode 100644
>>> index ..7bb11f3fdf24
>>> --- /dev/null
>>> +++ b/share/terminfo/Makefile
>>> @@ -0,0 +1,34 @@
>>> +PACKAGE=   runtime
>>> +
>>> +.PATH: ${SRCTOP}/contrib/ncurses/misc
>>> +TINFOBUILDDIR= ${.OBJDIR}/builddir
>>> +CLEANDIRS+=builddir
>>> +
>>> +.include 
>>> +
>>> +.if !defined(_SKIP_BUILD)
>>> +all: terminfo
>>> +.endif
>>> +META_TARGETS+= terminfo install-terminfo
>>> +
>>> +terminfo: terminfo.src
>>> +   mkdir -p ${TINFOBUILDDIR}
>>> +   ${TIC_CMD} -x -o ${TINFOBUILDDIR} ${.ALLSRC}
>>> +
>>> +.if make(*install*)
>>> +TINFOS!=cd ${TINFOBUILDDIR} && find * -type f | LC_ALL=C sort
>>> +TINFOSDIRS=${TINFOS:C/(.).*/\1/g:O:u}
>>> +.endif
>>> +
>>> +beforeinstall: install-terminfo
>>> +install-terminfo:
>>> +   mkdir -p ${DESTDIR}/usr/share/terminfo
>>> +   cd ${DESTDIR}/usr/share/terminfo; mkdir -p ${TINFOSDIRS}
>>> +.for f in ${TINFOS}
>>> +   ${INSTALL} ${TAG_ARGS} \
>>> +   -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
>>> +   ${TINFOBUILDDIR}/${f} ${DESTDIR}/usr/share/terminfo/${f}
>>> +.endfor
>>> +
>>> +.include 
>>> +
>>> 
>> 
>> I think this had some unintended consequences, a POLA violation that should 
>> be documented. Our termcap didn't support alternate screen buffers while 
>> terminfo does. Termcap did through t_te and t_ti but we didn't use them. 
>> Terminfo as delivered from the ncurses factory does supply rmcup and smcup; 
>> our fullscreen apps such as nvi and top see them and use the alternate 
>> screen buffer.
>> 
>> The use of the alternate screen buffer is one of the things I hate about 
>> Linux. After running vi or top I expect the output to remain on the screen 
>> so I can use some bit of information in my next command. We now have this 
>> behaviour too.
> 
> Oh, I so hate that mis-feature of Linux, please please tell me there is
> a simple knob to turn this off?  I believe LESS also does this kind
> of stuff, or atleast "man" on linux does, and that pees me off to no
> end when I quit the man page and what I wanted is no longer on the screen.

less -X may be what you want (or LESS="-X").

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 2a50a9de8340 - main - terminfo: add terminfo database

2021-02-26 Thread Jessica Clarke
On 26 Feb 2021, at 17:58, Alexey Dokuchaev  wrote:
> 
> On Fri, Feb 26, 2021 at 09:30:43AM -0800, Rodney W. Grimes wrote:
>> ...
>> Oh, I so hate that mis-feature of Linux, please please tell me there is
>> a simple knob to turn this off?  I believe LESS also does this kind
>> of stuff, or atleast "man" on linux does, and that pees me off to no
>> end when I quit the man page and what I wanted is no longer on the screen.
> 
> Everyone I know hates it; GNU/Linux folks apparently not pissed by this
> just because they haven't seen a better OS (e.g., FreeBSD).

I use both, I don't hate it. The only time I dislike it is when my SSH
connection drops whilst the alternate buffer is still in use, as that
can get confusing, but most of the time I'm grateful that my scroll
back isn't a mess of stuff I've since closed. Please don't spread
ill-founded absolutisms; that or you need to be aware of people outside
your circle of like-minded individuals.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 7bfd84444e6f - main - Provide a man page for VOP_SETLABEL(9).

2021-02-27 Thread Jessica Clarke
On 27 Feb 2021, at 16:52, Robert Watson  wrote:
> 
> The branch main has been updated by rwatson:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=7bfd8e6ff182abac2e08d6efcd2dc9ddc944
> 
> commit 7bfd8e6ff182abac2e08d6efcd2dc9ddc944
> Author: Robert Watson 
> AuthorDate: 2021-02-27 16:51:00 +
> Commit: Robert Watson 
> CommitDate: 2021-02-27 16:51:13 +
> 
>Provide a man page for VOP_SETLABEL(9).
> 
>MFC after:  3 days
> ---
> share/man/man9/VOP_SETLABEL.9 | 128 ++
> 1 file changed, 128 insertions(+)
> 
> diff --git a/share/man/man9/VOP_SETLABEL.9 b/share/man/man9/VOP_SETLABEL.9
> new file mode 100644
> index ..8b7e54e515cc
> --- /dev/null
> +++ b/share/man/man9/VOP_SETLABEL.9
> @@ -0,0 +1,128 @@
> +.\"-
> +.\" Copyright (c) 2021 Robert N. M. Watson
> +.\" All rights reserved.
> +.\"
> +.\" Redistribution and use in source and binary forms, with or without
> +.\" modification, are permitted provided that the following conditions
> +.\" are met:
> +.\" 1. Redistributions of source code must retain the above copyright
> +.\"notice, this list of conditions and the following disclaimer.
> +.\" 2. Redistributions in binary form must reproduce the above copyright
> +.\"notice, this list of conditions and the following disclaimer in the
> +.\"documentation and/or other materials provided with the distribution.
> +.\"
> +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
> PURPOSE
> +.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
> CONSEQUENTIAL
> +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 
> STRICT
> +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> +.\" SUCH DAMAGE.
> +.\"
> +.\" $FreeBSD$
> +.\"
> +.Dd February 27, 2021
> +.Dt VOP_SETLABEL 9
> +.Os
> +.Sh NAME
> +.Nm VOP_SETLABEL
> +.Nd persistently store an updated MAC label on a vnode
> +.Sh SYNOPSIS
> +.In sys/param.h
> +.In sys/vnode.h
> +.In security/mac.h
> +.Ft int
> +.Fn VOP_SETLABEL "struct vnode *vp" "label *label"
> +.Sh DESCRIPTION
> +This vnode call is made by
> +.Xr mac 9
> +file relabeling operation has been authorized, and the filesystem must now be

I think you're missing some words at the start of this line?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 7bfd84444e6f - main - Provide a man page for VOP_SETLABEL(9).

2021-02-27 Thread Jessica Clarke
On 27 Feb 2021, at 16:59, Robert Watson  wrote:
> 
> On Sat, 27 Feb 2021, Jessica Clarke wrote:
> 
>>> +This vnode call is made by
>>> +.Xr mac 9
>>> +file relabeling operation has been authorized, and the filesystem must now 
>>> be
>> 
>> I think you're missing some words at the start of this line?
> 
> Indeed - the word "once".  I'll pause a few minutes before fixing it in case 
> you spot anything else :-).

Well, that and an indefinite article?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 0b7472b3d8d2 - main - Mount the EFI system partition (ESP) on newly-installed systems.

2021-02-27 Thread Jessica Clarke
On 28 Feb 2021, at 01:22, Brandon Bergren  wrote:
> 
> On Sat, Feb 27, 2021, at 7:10 PM, Brandon Bergren wrote:
>> This is mistakenly detecting pseries powerpc64* as an EFI platform and 
>> causing install to error out. Please add back the uname checks so this 
>> code doesn't run on powerpc*.
> 
> Specifically, the /boot/efi stuff in usr.sbin/bsdinstall/scripts/bootconfig 
> should not run on mips / 32 bit ARM / powerpc* systems. I believe /boot/efi 
> is always created so it can't be used to infer existence of EFI.

32-bit Arm can boot via EFI. Just mips* and powerpc*.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 066dab17e7a4 - main - riscv: Fix whitespace issues in fabs added in 524b018d2004

2021-03-01 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=066dab17e7a4a78d43dbcef8119960ddc8090a73

commit 066dab17e7a4a78d43dbcef8119960ddc8090a73
Author: Jessica Clarke 
AuthorDate: 2021-03-01 14:01:13 +
Commit: Jessica Clarke 
CommitDate: 2021-03-01 15:19:36 +

riscv: Fix whitespace issues in fabs added in 524b018d2004
---
 lib/libc/riscv/gen/fabs.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/libc/riscv/gen/fabs.S b/lib/libc/riscv/gen/fabs.S
index 09042af3b4c0..036d50eddf90 100644
--- a/lib/libc/riscv/gen/fabs.S
+++ b/lib/libc/riscv/gen/fabs.S
@@ -43,8 +43,8 @@ ENTRY(fabs)
 #ifdef __riscv_float_abi_double
fabs.d  fa0, fa0
 #else
-   slli a0,a0,1
-   srli a0,a0,1
+   sllia0, a0, 1
+   srlia0, a0, 1
 #endif
ret
 END(fabs)
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 28d945204ea1 - main - Handle functions that use a nop in the arm64 fbt

2021-03-03 Thread Jessica Clarke
On 3 Mar 2021, at 14:26, Andrew Turner  wrote:
> 
> The branch main has been updated by andrew:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=28d945204ea1014d7de6906af8470ed8b3311335
> 
> commit 28d945204ea1014d7de6906af8470ed8b3311335
> Author: Andrew Turner 
> AuthorDate: 2021-01-13 11:08:19 +
> Commit: Andrew Turner 
> CommitDate: 2021-03-03 14:18:03 +
> 
>Handle functions that use a nop in the arm64 fbt
> 
>To trace leaf asm functions we can insert a single nop instruction as
>the first instruction in a function and trigger off this.
> 
>Reviewed by:gnn
>Sponsored by:   Innovate UK
>Differential Revision:  https://reviews.freebsd.org/D28132
> ---
> sys/arm64/include/asm.h|  8 +++-
> .../contrib/opensolaris/uts/common/sys/dtrace.h|  2 +
> sys/cddl/dev/dtrace/aarch64/dtrace_subr.c  |  5 +++
> sys/cddl/dev/fbt/aarch64/fbt_isa.c | 51 ++
> 4 files changed, 46 insertions(+), 20 deletions(-)
> 
> diff --git a/sys/arm64/include/asm.h b/sys/arm64/include/asm.h
> index 05e618500e59..32b79d256e80 100644
> --- a/sys/arm64/include/asm.h
> +++ b/sys/arm64/include/asm.h
> @@ -38,9 +38,15 @@
> 
> #define   _C_LABEL(x) x
> 
> +#ifdef KDTRACE_HOOKS
> +#define  DTRACE_NOP  nop
> +#else
> +#define  DTRACE_NOP
> +#endif
> +
> #define   LENTRY(sym) \
>   .text; .align 2; .type sym,#function; sym:  \
> - .cfi_startproc
> + .cfi_startproc; DTRACE_NOP
> #define   ENTRY(sym)  \
>   .globl sym; LENTRY(sym)

Doesn't this mean ENTRY incorrectly also has the nop?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 28d945204ea1 - main - Handle functions that use a nop in the arm64 fbt

2021-03-03 Thread Jessica Clarke
On 3 Mar 2021, at 14:29, Jessica Clarke  wrote:
> On 3 Mar 2021, at 14:26, Andrew Turner  wrote:
>> 
>> The branch main has been updated by andrew:
>> 
>> URL: 
>> https://cgit.FreeBSD.org/src/commit/?id=28d945204ea1014d7de6906af8470ed8b3311335
>> 
>> commit 28d945204ea1014d7de6906af8470ed8b3311335
>> Author: Andrew Turner 
>> AuthorDate: 2021-01-13 11:08:19 +
>> Commit: Andrew Turner 
>> CommitDate: 2021-03-03 14:18:03 +
>> 
>>   Handle functions that use a nop in the arm64 fbt
>> 
>>   To trace leaf asm functions we can insert a single nop instruction as
>>   the first instruction in a function and trigger off this.
>> 
>>   Reviewed by:gnn
>>   Sponsored by:   Innovate UK
>>   Differential Revision:  https://reviews.freebsd.org/D28132
>> ---
>> sys/arm64/include/asm.h|  8 +++-
>> .../contrib/opensolaris/uts/common/sys/dtrace.h|  2 +
>> sys/cddl/dev/dtrace/aarch64/dtrace_subr.c  |  5 +++
>> sys/cddl/dev/fbt/aarch64/fbt_isa.c | 51 
>> ++
>> 4 files changed, 46 insertions(+), 20 deletions(-)
>> 
>> diff --git a/sys/arm64/include/asm.h b/sys/arm64/include/asm.h
>> index 05e618500e59..32b79d256e80 100644
>> --- a/sys/arm64/include/asm.h
>> +++ b/sys/arm64/include/asm.h
>> @@ -38,9 +38,15 @@
>> 
>> #define  _C_LABEL(x) x
>> 
>> +#ifdef KDTRACE_HOOKS
>> +#define DTRACE_NOP  nop
>> +#else
>> +#define DTRACE_NOP
>> +#endif
>> +
>> #define  LENTRY(sym) \
>>  .text; .align 2; .type sym,#function; sym:  \
>> -.cfi_startproc
>> +.cfi_startproc; DTRACE_NOP
>> #define  ENTRY(sym)  \
>>  .globl sym; LENTRY(sym)
> 
> Doesn't this mean ENTRY incorrectly also has the nop?

Hm, right, the L in LENTRY means local not leaf. Isn't this a problem
though? (L)ENTRY are perfectly legal to use for non-leaf assembly
functions today. Shouldn't there be separate ones specifically for leaf
functions if you want to treat them differently?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 28d945204ea1 - main - Handle functions that use a nop in the arm64 fbt

2021-03-03 Thread Jessica Clarke
On 3 Mar 2021, at 14:55, Andrew Turner  wrote:
> 
>> On 3 Mar 2021, at 14:37, Jessica Clarke  wrote:
>> 
>> On 3 Mar 2021, at 14:29, Jessica Clarke  wrote:
>>> On 3 Mar 2021, at 14:26, Andrew Turner  wrote:
>>>> 
>>>> The branch main has been updated by andrew:
>>>> 
>>>> URL: 
>>>> https://cgit.FreeBSD.org/src/commit/?id=28d945204ea1014d7de6906af8470ed8b3311335
>>>> 
>>>> commit 28d945204ea1014d7de6906af8470ed8b3311335
>>>> Author: Andrew Turner 
>>>> AuthorDate: 2021-01-13 11:08:19 +
>>>> Commit: Andrew Turner 
>>>> CommitDate: 2021-03-03 14:18:03 +
>>>> 
>>>>  Handle functions that use a nop in the arm64 fbt
>>>> 
>>>>  To trace leaf asm functions we can insert a single nop instruction as
>>>>  the first instruction in a function and trigger off this.
>>>> 
>>>>  Reviewed by:gnn
>>>>  Sponsored by:   Innovate UK
>>>>  Differential Revision:  https://reviews.freebsd.org/D28132
>>>> ---
>>>> sys/arm64/include/asm.h|  8 +++-
>>>> .../contrib/opensolaris/uts/common/sys/dtrace.h|  2 +
>>>> sys/cddl/dev/dtrace/aarch64/dtrace_subr.c  |  5 +++
>>>> sys/cddl/dev/fbt/aarch64/fbt_isa.c | 51 
>>>> ++
>>>> 4 files changed, 46 insertions(+), 20 deletions(-)
>>>> 
>>>> diff --git a/sys/arm64/include/asm.h b/sys/arm64/include/asm.h
>>>> index 05e618500e59..32b79d256e80 100644
>>>> --- a/sys/arm64/include/asm.h
>>>> +++ b/sys/arm64/include/asm.h
>>>> @@ -38,9 +38,15 @@
>>>> 
>>>> #define_C_LABEL(x) x
>>>> 
>>>> +#ifdef KDTRACE_HOOKS
>>>> +#define   DTRACE_NOP  nop
>>>> +#else
>>>> +#define   DTRACE_NOP
>>>> +#endif
>>>> +
>>>> #defineLENTRY(sym) \
>>>>.text; .align 2; .type sym,#function; sym:  \
>>>> -  .cfi_startproc
>>>> +  .cfi_startproc; DTRACE_NOP
>>>> #defineENTRY(sym)  \
>>>>.globl sym; LENTRY(sym)
>>> 
>>> Doesn't this mean ENTRY incorrectly also has the nop?
>> 
>> Hm, right, the L in LENTRY means local not leaf. Isn't this a problem
>> though? (L)ENTRY are perfectly legal to use for non-leaf assembly
>> functions today. Shouldn't there be separate ones specifically for leaf
>> functions if you want to treat them differently?
> 
> Other than early boot handling, pmap_switch, and the exception handlers I 
> think we only have a few non-leaf asm functions on arm64. The only ones I can 
> think of use tail recursion, e.g. memmove -> memcpy when possible. Other than 
> exception handlers these functions don’t have the needed instructions to 
> manage the stack frame as they don’t use any stack space. I decided it was 
> easier to add the nop instruction to the start of function than try to create 
> an unneeded stack frame.

I don't contest that. My problem is that there is now a hidden
requirement that (L)ENTRY only be used for leaf functions lest you get
broken FBT for them. That is a surprising restriction, which to me
should be indicated by having a different macro name from the generic
(L)ENTRY shared across most (all?) ports. Despite its flaws, MIPS does
have special LEAF macros that are distinct from the others.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 28d945204ea1 - main - Handle functions that use a nop in the arm64 fbt

2021-03-03 Thread Jessica Clarke
> On 3 Mar 2021, at 15:09, Andrew Turner  wrote:
> 
>> 
>> On 3 Mar 2021, at 14:59, Jessica Clarke  wrote:
>> 
>> On 3 Mar 2021, at 14:55, Andrew Turner  wrote:
>>> 
>>>> On 3 Mar 2021, at 14:37, Jessica Clarke  wrote:
>>>> 
>>>> On 3 Mar 2021, at 14:29, Jessica Clarke  wrote:
>>>>> On 3 Mar 2021, at 14:26, Andrew Turner  wrote:
>>>>>> 
>>>>>> The branch main has been updated by andrew:
>>>>>> 
>>>>>> URL: 
>>>>>> https://cgit.FreeBSD.org/src/commit/?id=28d945204ea1014d7de6906af8470ed8b3311335
>>>>>> 
>>>>>> commit 28d945204ea1014d7de6906af8470ed8b3311335
>>>>>> Author: Andrew Turner 
>>>>>> AuthorDate: 2021-01-13 11:08:19 +
>>>>>> Commit: Andrew Turner 
>>>>>> CommitDate: 2021-03-03 14:18:03 +
>>>>>> 
>>>>>> Handle functions that use a nop in the arm64 fbt
>>>>>> 
>>>>>> To trace leaf asm functions we can insert a single nop instruction as
>>>>>> the first instruction in a function and trigger off this.
>>>>>> 
>>>>>> Reviewed by:gnn
>>>>>> Sponsored by:   Innovate UK
>>>>>> Differential Revision:  https://reviews.freebsd.org/D28132
>>>>>> ---
>>>>>> sys/arm64/include/asm.h|  8 +++-
>>>>>> .../contrib/opensolaris/uts/common/sys/dtrace.h|  2 +
>>>>>> sys/cddl/dev/dtrace/aarch64/dtrace_subr.c  |  5 +++
>>>>>> sys/cddl/dev/fbt/aarch64/fbt_isa.c | 51 
>>>>>> ++
>>>>>> 4 files changed, 46 insertions(+), 20 deletions(-)
>>>>>> 
>>>>>> diff --git a/sys/arm64/include/asm.h b/sys/arm64/include/asm.h
>>>>>> index 05e618500e59..32b79d256e80 100644
>>>>>> --- a/sys/arm64/include/asm.h
>>>>>> +++ b/sys/arm64/include/asm.h
>>>>>> @@ -38,9 +38,15 @@
>>>>>> 
>>>>>> #define  _C_LABEL(x) x
>>>>>> 
>>>>>> +#ifdef KDTRACE_HOOKS
>>>>>> +#define DTRACE_NOP  nop
>>>>>> +#else
>>>>>> +#define DTRACE_NOP
>>>>>> +#endif
>>>>>> +
>>>>>> #define  LENTRY(sym) \
>>>>>>  .text; .align 2; .type sym,#function; sym:  \
>>>>>> -.cfi_startproc
>>>>>> +.cfi_startproc; DTRACE_NOP
>>>>>> #define  ENTRY(sym)  \
>>>>>>  .globl sym; LENTRY(sym)
>>>>> 
>>>>> Doesn't this mean ENTRY incorrectly also has the nop?
>>>> 
>>>> Hm, right, the L in LENTRY means local not leaf. Isn't this a problem
>>>> though? (L)ENTRY are perfectly legal to use for non-leaf assembly
>>>> functions today. Shouldn't there be separate ones specifically for leaf
>>>> functions if you want to treat them differently?
>>> 
>>> Other than early boot handling, pmap_switch, and the exception handlers I 
>>> think we only have a few non-leaf asm functions on arm64. The only ones I 
>>> can think of use tail recursion, e.g. memmove -> memcpy when possible. 
>>> Other than exception handlers these functions don’t have the needed 
>>> instructions to manage the stack frame as they don’t use any stack space. I 
>>> decided it was easier to add the nop instruction to the start of function 
>>> than try to create an unneeded stack frame.
>> 
>> I don't contest that. My problem is that there is now a hidden
>> requirement that (L)ENTRY only be used for leaf functions lest you get
>> broken FBT for them. That is a surprising restriction, which to me
>> should be indicated by having a different macro name from the generic
>> (L)ENTRY shared across most (all?) ports. Despite its flaws, MIPS does
>> have special LEAF macros that are distinct from the others.
> 
> Why would you get broken FBT? All it cares about is finding an instruction it 
> can emulate and replace it with a specific breakpoint. In a non-leaf asm 
> function we will place a nop as the first instruction followed by the 
> standard stack frame manipulation instructions. In this case the nop is 
> unneeded, but should add minimal overhead if such a function is added.
> 
> I only mentioned leaf functions in the commit message as an example of 
> something that we may not have previously been able to trace due to a lack of 
> stack usage.

Oh I see, I didn't read the commit properly, I assumed it was to
watermark leaf functions for better stack traces. My bad.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: f2f8405cf6b5 - main - if_vtbe: Add missing includes to fix build

2021-03-08 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=f2f8405cf6b50a9d91acc02073abf1062d9d34f4

commit f2f8405cf6b50a9d91acc02073abf1062d9d34f4
Author: Jessica Clarke 
AuthorDate: 2021-03-08 20:47:29 +
Commit: Jessica Clarke 
CommitDate: 2021-03-08 20:48:48 +

if_vtbe: Add missing includes to fix build

PR: 254137
Reported by:Mina Galić 
MFC after:  3 days
Fixes:  f8bc74e2f4a5 ("tap: add support for virtio-net offloads")
---
 sys/dev/beri/virtio/network/if_vtbe.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sys/dev/beri/virtio/network/if_vtbe.c 
b/sys/dev/beri/virtio/network/if_vtbe.c
index 69b40588a974..5959b621954b 100644
--- a/sys/dev/beri/virtio/network/if_vtbe.c
+++ b/sys/dev/beri/virtio/network/if_vtbe.c
@@ -70,6 +70,10 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: e3394851b5da - stable/13 - if_vtbe: Add missing includes to fix build

2021-03-08 Thread Jessica Clarke
The branch stable/13 has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=e3394851b5da6ec46e655a4f801cd6cac0840445

commit e3394851b5da6ec46e655a4f801cd6cac0840445
Author: Jessica Clarke 
AuthorDate: 2021-03-08 20:47:29 +
Commit: Jessica Clarke 
CommitDate: 2021-03-08 21:04:40 +

if_vtbe: Add missing includes to fix build

PR: 254137
Reported by:Mina Galić 
Fixes:  f8bc74e2f4a5 ("tap: add support for virtio-net offloads")

(cherry picked from commit f2f8405cf6b50a9d91acc02073abf1062d9d34f4)
---
 sys/dev/beri/virtio/network/if_vtbe.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sys/dev/beri/virtio/network/if_vtbe.c 
b/sys/dev/beri/virtio/network/if_vtbe.c
index 69b40588a974..5959b621954b 100644
--- a/sys/dev/beri/virtio/network/if_vtbe.c
+++ b/sys/dev/beri/virtio/network/if_vtbe.c
@@ -70,6 +70,10 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: a239b47cc966 - releng/13.0 - if_vtbe: Add missing includes to fix build

2021-03-08 Thread Jessica Clarke
The branch releng/13.0 has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=a239b47cc966165d6f515c9787834abb7742cc95

commit a239b47cc966165d6f515c9787834abb7742cc95
Author: Jessica Clarke 
AuthorDate: 2021-03-08 20:47:29 +
Commit: Jessica Clarke 
CommitDate: 2021-03-08 21:33:27 +

if_vtbe: Add missing includes to fix build

PR: 254137
Reported by:Mina Galić 
Fixes:  f8bc74e2f4a5 ("tap: add support for virtio-net offloads")
Approved by:re (gjb)

(cherry picked from commit f2f8405cf6b50a9d91acc02073abf1062d9d34f4)
(cherry picked from commit e3394851b5da6ec46e655a4f801cd6cac0840445)
---
 sys/dev/beri/virtio/network/if_vtbe.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sys/dev/beri/virtio/network/if_vtbe.c 
b/sys/dev/beri/virtio/network/if_vtbe.c
index 69b40588a974..5959b621954b 100644
--- a/sys/dev/beri/virtio/network/if_vtbe.c
+++ b/sys/dev/beri/virtio/network/if_vtbe.c
@@ -70,6 +70,10 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: c328f64d8107 - main - arm64: Fix COMPAT_FREEBSD32.

2021-03-10 Thread Jessica Clarke
On 10 Mar 2021, at 18:07, Olivier Houchard  wrote:
> 
> The branch main has been updated by cognet:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=c328f64d81079bad5064c8a387883df50ab5aaed
> 
> commit c328f64d81079bad5064c8a387883df50ab5aaed
> Author: Olivier Houchard 
> AuthorDate: 2021-03-10 18:01:41 +
> Commit: Olivier Houchard 
> CommitDate: 2021-03-10 18:06:42 +
> 
>arm64: Fix COMPAT_FREEBSD32.
> 
>The ENTRY() macro was modified by commit
>28d945204ea1014d7de6906af8470ed8b3311335 to add an optional NOP instruction
>at the beginning of the function. It is of course an arm64 instruction, so
>unsuitable for the 32bits sigcode. So just use EENTRY() instead for
>aarch32_sigcode. This should fix receiving signals when running 32bits
>binaries on FreeBSD/arm64.

Hmm, that's a good point, does the extra nop for the AArch64 sigcode
cause issues for gdb detecting it?

Perhaps we should upstream CheriBSD's SIGCODE macros?..

Jess




Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 29a55fd09b0a - main - dtc: Sync with upstream commit 26a0fe5

2023-09-28 Thread Jessica Clarke
On 26 Sep 2023, at 18:00, Ed Maste  wrote:
> 
> The branch main has been updated by emaste:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=29a55fd09b0a3cc4c888f7a630fde41694699343
> 
> commit 29a55fd09b0a3cc4c888f7a630fde41694699343
> Author: Jose Luis Duran 
> AuthorDate: 2023-09-26 16:37:52 +
> Commit: Ed Maste 
> CommitDate: 2023-09-26 16:59:17 +
> 
>dtc: Sync with upstream commit 26a0fe5
> 
>- 0206c0f ("Handle top-level /delete-node/ directives.")
>- d612a9e ("Remove C++11 standard constrain")
>- Remove extra white lines after the $FreeBSD$ tag removal
> 
>Reviewed by:kevans (earlier), theraven, emaste
>Differential Revision: https://reviews.freebsd.org/D41482
> ---
> usr.bin/dtc/HACKING  |   1 -
> usr.bin/dtc/Makefile |   3 --
> usr.bin/dtc/fdt.cc   | 134 ---
> usr.bin/dtc/fdt.hh   |  24 ++---
> 4 files changed, 121 insertions(+), 41 deletions(-)
> 
> diff --git a/usr.bin/dtc/HACKING b/usr.bin/dtc/HACKING
> index 9447c4f6ebf9..ef858c8885c0 100644
> --- a/usr.bin/dtc/HACKING
> +++ b/usr.bin/dtc/HACKING
> @@ -1,4 +1,3 @@
> -
> Notes for people hacking on dtc
> ===
> 
> diff --git a/usr.bin/dtc/Makefile b/usr.bin/dtc/Makefile
> index d242ed80e8b1..d7661ae164c3 100644
> --- a/usr.bin/dtc/Makefile
> +++ b/usr.bin/dtc/Makefile
> @@ -1,4 +1,3 @@
> -
> PROG_CXX=dtc
> SRCS= dtc.cc input_buffer.cc string.cc dtb.cc fdt.cc checking.cc
> MAN= dtc.1
> @@ -7,8 +6,6 @@ WARNS?= 3
> 
> CXXFLAGS+= -fno-rtti -fno-exceptions
> 
> -CXXSTD= c++11

This broke building FreeBSD on macOS, as it defaults to C++98 not
C++11, despite using modern Clang. Unlike CSTD there is no CXXSTD
default in bsd.sys.mk. Please reinstate this until we have a better way
to deal with CXXSTD.

(See 
https://github.com/freebsd/freebsd-src/actions/runs/6341785142/job/17226170311)

Jess




Re: git: 29a55fd09b0a - main - dtc: Sync with upstream commit 26a0fe5

2023-09-28 Thread Jessica Clarke
On 28 Sep 2023, at 20:48, Jessica Clarke  wrote:
> 
> On 26 Sep 2023, at 18:00, Ed Maste  wrote:
>> 
>> The branch main has been updated by emaste:
>> 
>> URL: 
>> https://cgit.FreeBSD.org/src/commit/?id=29a55fd09b0a3cc4c888f7a630fde41694699343
>> 
>> commit 29a55fd09b0a3cc4c888f7a630fde41694699343
>> Author: Jose Luis Duran 
>> AuthorDate: 2023-09-26 16:37:52 +
>> Commit: Ed Maste 
>> CommitDate: 2023-09-26 16:59:17 +
>> 
>>   dtc: Sync with upstream commit 26a0fe5
>> 
>>   - 0206c0f ("Handle top-level /delete-node/ directives.")
>>   - d612a9e ("Remove C++11 standard constrain")
>>   - Remove extra white lines after the $FreeBSD$ tag removal
>> 
>>   Reviewed by:kevans (earlier), theraven, emaste
>>   Differential Revision: https://reviews.freebsd.org/D41482
>> ---
>> usr.bin/dtc/HACKING  |   1 -
>> usr.bin/dtc/Makefile |   3 --
>> usr.bin/dtc/fdt.cc   | 134 
>> ---
>> usr.bin/dtc/fdt.hh   |  24 ++---
>> 4 files changed, 121 insertions(+), 41 deletions(-)
>> 
>> diff --git a/usr.bin/dtc/HACKING b/usr.bin/dtc/HACKING
>> index 9447c4f6ebf9..ef858c8885c0 100644
>> --- a/usr.bin/dtc/HACKING
>> +++ b/usr.bin/dtc/HACKING
>> @@ -1,4 +1,3 @@
>> -
>> Notes for people hacking on dtc
>> ===
>> 
>> diff --git a/usr.bin/dtc/Makefile b/usr.bin/dtc/Makefile
>> index d242ed80e8b1..d7661ae164c3 100644
>> --- a/usr.bin/dtc/Makefile
>> +++ b/usr.bin/dtc/Makefile
>> @@ -1,4 +1,3 @@
>> -
>> PROG_CXX=dtc
>> SRCS= dtc.cc input_buffer.cc string.cc dtb.cc fdt.cc checking.cc
>> MAN= dtc.1
>> @@ -7,8 +6,6 @@ WARNS?= 3
>> 
>> CXXFLAGS+= -fno-rtti -fno-exceptions
>> 
>> -CXXSTD= c++11
> 
> This broke building FreeBSD on macOS, as it defaults to C++98 not
> C++11, despite using modern Clang. Unlike CSTD there is no CXXSTD
> default in bsd.sys.mk. Please reinstate this until we have a better way
> to deal with CXXSTD.
> 
> (See 
> https://github.com/freebsd/freebsd-src/actions/runs/6341785142/job/17226170311)

In fact dtc now requires C++14 due to using auto in lambdas, and
upstream’s build systems explicitly use C++17.

Jess




Re: git: f147cf0ee2b2 - main - dtc: Ensure it is built in C++17 mode

2023-09-29 Thread Jessica Clarke
On 29 Sep 2023, at 14:27, Ed Maste  wrote:
> 
> The branch main has been updated by emaste:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=f147cf0ee2b2642c0a133a71c8a5dc018518d923
> 
> commit f147cf0ee2b2642c0a133a71c8a5dc018518d923
> Author: Jose Luis Duran 
> AuthorDate: 2023-09-29 13:24:32 +
> Commit: Ed Maste 
> CommitDate: 2023-09-29 13:26:51 +
> 
>dtc: Ensure it is built in C++17 mode
> 
>Explicitly specify the C++ standard to be used in the Makefile.
>This prevents macOS cross-builds from using the default gnu++98 and
>fail.  This syncs dtc with upstream commit
>39a58cfaab7d55c7975ebf905d859ba91a369fa0.

Thank you.

Jess

>Reviewed by: emaste
>Fixes: 29a55fd09b0a ("dtc: Sync with upstream commit 26a0fe5")
>Differential Revision: https://reviews.freebsd.org/D42006
> ---
> usr.bin/dtc/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/usr.bin/dtc/Makefile b/usr.bin/dtc/Makefile
> index d7661ae164c3..9b1aff13511f 100644
> --- a/usr.bin/dtc/Makefile
> +++ b/usr.bin/dtc/Makefile
> @@ -6,6 +6,8 @@ WARNS?= 3
> 
> CXXFLAGS+= -fno-rtti -fno-exceptions
> 
> +CXXSTD= c++17
> +
> NO_SHARED?=NO
> 
> .include 




Re: git: d09a64e15d8f - main - arm64: Enable kernel branch protection

2023-10-10 Thread Jessica Clarke
On 10 Oct 2023, at 10:53, Andrew Turner  wrote:
> 
> The branch main has been updated by andrew:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=d09a64e15d8fad6588b9aad62979f20afa8441df
> 
> commit d09a64e15d8fad6588b9aad62979f20afa8441df
> Author: Andrew Turner 
> AuthorDate: 2023-10-02 15:55:31 +
> Commit: Andrew Turner 
> CommitDate: 2023-10-10 09:52:16 +
> 
>arm64: Enable kernel branch protection

Can we please put this kind of thing behind an option? Users may want
to be able to turn it off, and we surely will in CheriBSD for
pure-capability kernels.

This applies to any other security features in your pipeline too.

Jess

>Add the build flags to enable branch protection on arm64. This enable
>the use of PAC and BTI in the kernel.
> 
>For PAC we already install the kernel keys when entering the kernel
>from userspace so this will start using these to sign the stack.
> 
>For BTI we need to mark the kernel page tables with a new guarded page
>field. As this will require all code that could be reached through a
>function pointer with an appropriate branch target instruction we
>are enabling this before setting the field.
> 
>As the pointer authentication support shouldn't be reached via a
>function pointer it is safe to not enable the use of BTI there.
> 
>Reviewed by:markj
>Sponsored by:   Arm Ltd
>Differential Revision:  https://reviews.freebsd.org/D42079
> ---
> sys/conf/kern.mk | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
> index b508bc81b5f0..72b7387d3959 100644
> --- a/sys/conf/kern.mk
> +++ b/sys/conf/kern.mk
> @@ -140,6 +140,8 @@ INLINE_LIMIT?= 8000
> CFLAGS += -mgeneral-regs-only
> # Reserve x18 for pcpu data
> CFLAGS += -ffixed-x18
> +# Build with BTI+PAC
> +CFLAGS += -mbranch-protection=standard
> INLINE_LIMIT?= 8000
> .endif
> 




Re: git: 9eff6390718d - main - pf: remove COMPAT_FREEBSD14 #ifdef from pfvar.h

2023-10-19 Thread Jessica Clarke
On 19 Oct 2023, at 15:20, Kristof Provost  wrote:
> 
> The branch main has been updated by kp:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=9eff6390718d0fa67dffc6cd830b0bc6b815e8c4
> 
> commit 9eff6390718d0fa67dffc6cd830b0bc6b815e8c4
> Author: Kristof Provost 
> AuthorDate: 2023-10-19 10:06:29 +
> Commit: Kristof Provost 
> CommitDate: 2023-10-19 14:19:39 +
> 
>pf: remove COMPAT_FREEBSD14 #ifdef from pfvar.h
> 
>When userspace includes pfvar.h it doesn't get the kernel's COMPAT_*
>defines, so we end up not having required symbols in userspace. This
>caused the libpfctl port to fail to build.
> 
>libpfctl will be updated to use the new netlink-based state export code
>soon, which will also fix thix build issue.
> 
>Sponsored by:   Rubicon Communications, LLC ("Netgate")

That’s normally a feature to stop userspace using deprecated things.
Will you be reverting this once libpfctl is fixed? One could also hack
libpfctl instead to define COMPAT_FREEBSD14 temporarily (IIRC that’s
what was done for kbdcontrol to allow it to run on old kernels).

Jess




Re: git: 9eff6390718d - main - pf: remove COMPAT_FREEBSD14 #ifdef from pfvar.h

2023-10-19 Thread Jessica Clarke
On 19 Oct 2023, at 15:56, Kristof Provost  wrote:
> 
> On 19 Oct 2023, at 16:41, Jessica Clarke wrote:
>> On 19 Oct 2023, at 15:20, Kristof Provost  wrote:
>>> 
>>> The branch main has been updated by kp:
>>> 
>>> URL: 
>>> https://cgit.FreeBSD.org/src/commit/?id=9eff6390718d0fa67dffc6cd830b0bc6b815e8c4
>>> 
>>> commit 9eff6390718d0fa67dffc6cd830b0bc6b815e8c4
>>> Author: Kristof Provost 
>>> AuthorDate: 2023-10-19 10:06:29 +
>>> Commit: Kristof Provost 
>>> CommitDate: 2023-10-19 14:19:39 +
>>> 
>>>   pf: remove COMPAT_FREEBSD14 #ifdef from pfvar.h
>>> 
>>>   When userspace includes pfvar.h it doesn't get the kernel's COMPAT_*
>>>   defines, so we end up not having required symbols in userspace. This
>>>   caused the libpfctl port to fail to build.
>>> 
>>>   libpfctl will be updated to use the new netlink-based state export code
>>>   soon, which will also fix thix build issue.
>>> 
>>>   Sponsored by:   Rubicon Communications, LLC ("Netgate")
>> 
>> That’s normally a feature to stop userspace using deprecated things.
>> Will you be reverting this once libpfctl is fixed? One could also hack
>> libpfctl instead to define COMPAT_FREEBSD14 temporarily (IIRC that’s
>> what was done for kbdcontrol to allow it to run on old kernels).
>> 
> I wasn’t planning on that, no. The libpfctl port fix should land soon, but I 
> figured that it’d be better to keep the definitions, because userspace 
> doesn’t know if the kernel is built with or without COMPAT_FREEBSD14.
> I’m open to being persuaded that that’s a bad idea though.

Indeed it doesn’t, because it shouldn’t. The thinking is that userspace
should *never* explicitly use them, only the kernel to provide
compatibility with binaries built against older versions. Deliberately
exposing them to userspace is quite unusual and deemed generally dodgy.

Jess

> Long-term (i.e. by freebsd 16) the plan is for all of these ioctls to go away 
> (so the code for them will stay in 15, but not be in 16), but that does 
> depend on me doing a fair bit of work before then.
> 
> Best regards,
> Kristof





Re: git: fabf705f4b5a - main - pf: fix pf divert-to loop

2023-10-19 Thread Jessica Clarke
On 19 Oct 2023, at 17:14, Gleb Smirnoff  wrote:
> 
> On Thu, Oct 19, 2023 at 12:37:39PM +, Kristof Provost wrote:
> K> +++ b/sys/netinet/ip_var.h
> ...
> K> +/* pf specific mtag for divert(4) support */
> K> +enum { PF_DIVERT_MTAG_DIR_IN=1, PF_DIVERT_MTAG_DIR_OUT=2 };
> K> +struct pf_divert_mtag {
> K> + uint16_t idir; // initial pkt direction
> K> + uint16_t ndir; // a) divert(4) port upon initial diversion
> K> + // b) new direction upon pkt re-enter
> K> +};
> 
> This can be written as:
> 
> typedef enum {
>PF_DIVERT_MTAG_DIR_IN = 1,
>PF_DIVERT_MTAG_DIR_OUT = 2,
> } pf_mtag_dir;

You don’t need the typedef, whether you use it or not is a matter of taste.

> struct pf_divert_mtag {
>pf_mtag_dir idir; /* Initial packet direction. */
>union {
>pf_mtag_dir ndir; /* New direction after re-enter. */
>uint16_tport;/* Initial divert(4) port. */
>};
> };
> 
> The benefit is that in the debugger you will see PF_DIVERT_MTAG_DIR_IN instead
> of 1 when looking at a structure. And compilation time failure if anybody sets
> it to a wrong value. Using "port" instead of "ndir" when assigning a port
> improves readability of code.
> 
> This will grow structure from 4 bytes to 8, as enum is always an int. However,
> uma allocator backing m_tag_alloc() will allocate same amount of memory.

We have __enum_uint8(_decl) these days, one could easily add a 16-bit variant.

Jess




git: 1c1f229e9156 - main - libc: Strip plentiful trailing whitespace from aarch64+arm makecontext.c

2023-10-27 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=1c1f229e9156dd75cab5e0e3e586c5ef319d68ee

commit 1c1f229e9156dd75cab5e0e3e586c5ef319d68ee
Author: Jessica Clarke 
AuthorDate: 2023-10-28 01:45:06 +
Commit: Jessica Clarke 
CommitDate: 2023-10-28 01:45:06 +

libc: Strip plentiful trailing whitespace from aarch64+arm makecontext.c
---
 lib/libc/aarch64/gen/makecontext.c | 10 +-
 lib/libc/arm/gen/makecontext.c | 10 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/lib/libc/aarch64/gen/makecontext.c 
b/lib/libc/aarch64/gen/makecontext.c
index ae23ad87d3a2..d4dcffa6cd6f 100644
--- a/lib/libc/aarch64/gen/makecontext.c
+++ b/lib/libc/aarch64/gen/makecontext.c
@@ -40,16 +40,16 @@ void _ctx_start(void);
 
 void
 ctx_done(ucontext_t *ucp)
-{   
-   
+{
+
if (ucp->uc_link == NULL) {
exit(0);
-   } else {  
+   } else {
setcontext((const ucontext_t *)ucp->uc_link);
abort();
-   }  
+   }
 }
-   
+
 __weak_reference(__makecontext, makecontext);
 
 void
diff --git a/lib/libc/arm/gen/makecontext.c b/lib/libc/arm/gen/makecontext.c
index bf24e1f741c9..1051d4e4de15 100644
--- a/lib/libc/arm/gen/makecontext.c
+++ b/lib/libc/arm/gen/makecontext.c
@@ -43,15 +43,15 @@ extern void _ctx_start(void);
 
 void
 ctx_done(ucontext_t *ucp)
-{   
-   
+{
+
if (ucp->uc_link == NULL)
exit(0);
-   else {  
+   else {
setcontext((const ucontext_t *)ucp->uc_link);
abort();
-   }  
-}   
+   }
+}
 
 __weak_reference(__makecontext, makecontext);
 



Re: git: 3fd60a6b73ac - main - awk: Merge upstream 2nd Edition Awk Book

2023-11-15 Thread Jessica Clarke
On 14 Nov 2023, at 04:51, Warner Losh  wrote:
> 
> The branch main has been updated by imp:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=3fd60a6b73ac01a72df89751f173970fae4cae73
> 
> commit 3fd60a6b73ac01a72df89751f173970fae4cae73
> Merge: 194df014feeb 2e406c584fe4
> Author: Warner Losh 
> AuthorDate: 2023-11-02 16:32:01 +
> Commit: Warner Losh 
> CommitDate: 2023-11-14 04:49:34 +
> 
>awk: Merge upstream 2nd Edition Awk Book
> 
>Merge in the November 2nd, 2023 version of one true awk.
> 
>This brings in Unicode support, CSV support and a number of bug fixes.
> 
>Sponsored by:   Netflix
>Reviewed by:delphij
>Differential Revision:  https://reviews.freebsd.org/D42447

This seems to have broken the GitHub CI for cross-building; contrast:

https://github.com/freebsd/freebsd-src/actions/runs/6859373313

with:

https://github.com/freebsd/freebsd-src/actions/runs/6859316228

Has this broken makeobjops.awk somehow? If so it should be reproducible
on FreeBSD with BOOTSTRAP_ALL_TOOLS=1, or by rebuilding on an updated
system. Cross-building will just show it first because we always
bootstrap awk there, like many other tools.

Jess




Re: git: 7eb26be9c808 - main - arm64: Use adrp + :lo12: to load globals from asm

2023-11-15 Thread Jessica Clarke
On 15 Nov 2023, at 18:12, Andrew Turner  wrote:
> 
> The branch main has been updated by andrew:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=7eb26be9c8080686f64fdc0a28e5ae7839bbc82d
> 
> commit 7eb26be9c8080686f64fdc0a28e5ae7839bbc82d
> Author: Andrew Turner 
> AuthorDate: 2023-11-11 09:27:30 +
> Commit: Andrew Turner 
> CommitDate: 2023-11-15 18:05:08 +
> 
>arm64: Use adrp + :lo12: to load globals from asm
> 
>When loading a global variable we can use a pseudo-instruction similar
>to "ldr, xn, =global" to load the address of the symbol. As this is
>unlikely to be supported by a mov instruction a pc-relative load is
>used, with the absolute address written at the end of the function so
>it will be loaded.
> 
>This load can be partially replaced with an adrp instruction. This
>generates the address, aligned to a 4k boundary, using a pc-relative
>addition. Because the address is 4k-aligned we then update reading the
>global variable using a load with the offset of the load the low
>12-bits of the global. Arm64 assemblers have :lo12: to support this,
>e.g. "ldr xn, [xn, :lo12:global]".
> 
>The only remaining users of "ldr, xn, =global" that I can find are
>executed from the physical address space the kernel was loaded in and
>need an address in the kernels virtual address space. Because of this
>they can't use adrp.
> 
>Sponsored by:   Arm Ltd
>Differential Revision:  https://reviews.freebsd.org/D42565

I assume the motivation for this, which seems to be missing from the
description, is that it removes an unnecessary level of indirection,
rather than that there are issues with the PC-relative load literal
instruction not working, given that I doubt we’re hitting the 1 MiB
literal pool offset range limit in hand-written assembly?

Jess




Re: git: 9eecef052155 - main - Add an Armv8 rndr random number provider

2023-11-15 Thread Jessica Clarke
On 15 Nov 2023, at 18:12, Andrew Turner  wrote:
> 
> The branch main has been updated by andrew:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=9eecef052155646fbc5f8f533b952b372572d06a
> 
> commit 9eecef052155646fbc5f8f533b952b372572d06a
> Author: Andrew Turner 
> AuthorDate: 2023-11-15 17:42:02 +
> Commit: Andrew Turner 
> CommitDate: 2023-11-15 18:05:08 +
> 
>Add an Armv8 rndr random number provider
> 
>Armv8.5 adds an optional random number generator. This is implemented
>as two special registers one to read a random number, the other to
>re-seed the entropy pool before reading a random number. Both registers
>will set the condition flags to tell the caller they can't produce a
>random number in a reasonable amount of time.
> 
>Without a signal to reseed the entropy pool use the latter register
>to provide random numbers to the kernel pool. If at a later time we
>had a way to tell the provider if it needs to reseed or not we could
>use the former.
> 
>On an Amazon AWS Graviton3 VM this never failed, however this may not
>be the case on low end CPUs so retry reading the random number 10 times
>before returning an error.
> 
>Reviewed by:imp, delphij (csprng)
>Sponsored by:   The FreeBSD Foundation
>Sponsored by:   Arm Ltd
>Differential Revision:  https://reviews.freebsd.org/D35411
> ---
> sys/arm64/conf/std.dev   |   1 +
> sys/conf/files.arm64 |   2 +
> sys/dev/random/armv8rng.c| 135 +++
> sys/dev/random/random_harvestq.c |   1 +
> sys/modules/Makefile |   2 +
> sys/modules/armv8_rng/Makefile   |  11 
> sys/sys/random.h |   1 +
> 7 files changed, 153 insertions(+)
> 
> diff --git a/sys/arm64/conf/std.dev b/sys/arm64/conf/std.dev
> index 74d2407e0aec..0ebf2e775b11 100644
> --- a/sys/arm64/conf/std.dev
> +++ b/sys/arm64/conf/std.dev
> @@ -53,6 +53,7 @@ device vt_simplefb
> 
> # Pseudo devices.
> device crypto # core crypto support
> +device armv8_rng # Armv8.5 rndr RNG
> device loop # Network loopback
> device ether # Ethernet support
> device vlan # 802.1Q VLAN support
> diff --git a/sys/conf/files.arm64 b/sys/conf/files.arm64
> index 38b9e40463eb..9ccead6a98e1 100644
> --- a/sys/conf/files.arm64
> +++ b/sys/conf/files.arm64
> @@ -379,6 +379,8 @@ dev/psci/psci.c standard
> dev/psci/smccc_arm64.S standard
> dev/psci/smccc.c standard
> 
> +dev/random/armv8rng.c optional armv8_rng !random_loadable
> +
> dev/safexcel/safexcel.c optional safexcel fdt
> 
> dev/sdhci/sdhci_xenon.c optional sdhci_xenon sdhci
> diff --git a/sys/dev/random/armv8rng.c b/sys/dev/random/armv8rng.c
> new file mode 100644
> index ..3cca42a5bbf3
> --- /dev/null
> +++ b/sys/dev/random/armv8rng.c
> @@ -0,0 +1,135 @@
> +/*-
> + * Copyright (c) 2022 The FreeBSD Foundation
> + *
> + * This software was developed by Andrew Turner under sponsorship from
> + * the FreeBSD Foundation.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +static u_int random_rndr_read(void *, u_int);
> +
> +static bool has_rndr;
> +static struct random_source random_armv8_rndr = {
> + .rs_ident = "Armv8 rndr RNG",
> + .rs_source = RANDOM_PURE_ARMV8,
> + .rs_read = random_rndr_read,
> +};
> +
> +static inline int
> +random_rndr_read_one(u_long *buf)
> +{
> + u_long val;
> + int loop, ret;
> +
> + loop = 10;
> + do {
> + __asm __volatile(
> +".arch_extension rng   \n"
> +"mrs %0, rndrrs \n" /* Read the random number */
> 

Re: git: 3fd60a6b73ac - main - awk: Merge upstream 2nd Edition Awk Book

2023-11-15 Thread Jessica Clarke
On 15 Nov 2023, at 21:59, Warner Losh  wrote:
> 
> 
> 
> On Wed, Nov 15, 2023 at 9:52 AM Jessica Clarke  wrote:
>> On 14 Nov 2023, at 04:51, Warner Losh  wrote:
>> > 
>> > The branch main has been updated by imp:
>> > 
>> > URL: 
>> > https://cgit.FreeBSD.org/src/commit/?id=3fd60a6b73ac01a72df89751f173970fae4cae73
>> > 
>> > commit 3fd60a6b73ac01a72df89751f173970fae4cae73
>> > Merge: 194df014feeb 2e406c584fe4
>> > Author: Warner Losh 
>> > AuthorDate: 2023-11-02 16:32:01 +
>> > Commit: Warner Losh 
>> > CommitDate: 2023-11-14 04:49:34 +
>> > 
>> >awk: Merge upstream 2nd Edition Awk Book
>> > 
>> >Merge in the November 2nd, 2023 version of one true awk.
>> > 
>> >This brings in Unicode support, CSV support and a number of bug fixes.
>> > 
>> >Sponsored by:   Netflix
>> >Reviewed by:delphij
>> >Differential Revision:  https://reviews.freebsd.org/D42447
>> 
>> This seems to have broken the GitHub CI for cross-building; contrast:
>> 
>> https://github.com/freebsd/freebsd-src/actions/runs/6859373313
>> 
>> with:
>> 
>> https://github.com/freebsd/freebsd-src/actions/runs/6859316228
>> 
>> Has this broken makeobjops.awk somehow? If so it should be reproducible
>> on FreeBSD with BOOTSTRAP_ALL_TOOLS=1, or by rebuilding on an updated
>> system. Cross-building will just show it first because we always
>> bootstrap awk there, like many other tools.
> 
> It worked when it was the system awk for me...  But that might not be the most
> helpful observation.

For a clean kernel build?

> Why didn't it work for you/github's ci runs?

From GitHub (indentation sadly lost when copying):

> In file included from 
> /Users/runner/work/freebsd-src/freebsd-src/sys/cam/cam.c:45: 
> In file included from 
> /Users/runner/work/freebsd-src/freebsd-src/sys/cam/cam_ccb.h:1052: 
> In file included from 
> /Users/runner/work/freebsd-src/freebsd-src/sys/cam/mmc/mmc_bus.h:4: 
> In file included from 
> /Users/runner/work/freebsd-src/freebsd-src/sys/dev/mmc/bridge.h:57: 
> In file included from 
> /Users/runner/work/freebsd-src/freebsd-src/sys/sys/bus.h:787: 
> ./bus_if.h:217:35: error: expected ')' 
> int _unit); 
> ^ 
> ./bus_if.h:216:33: note: to match this '(' 
> typedef device_t bus_add_child_t(device_t _dev, u_int _order, const char 
> *_name 
> ^ 
> ./bus_if.h:241:41: error: expected ')' 
> const char *_name, int _unit) 
> ^ 
> ./bus_if.h:240:39: note: to match this '(' 
> static __inline device_t BUS_ADD_CHILD(device_t _dev, u_int _order 
> ^
> ...

Hence the assumption that makeobjops.awk has stopped working properly,
which is highly consistent with this being the first commit to fail in
CI. It looks like we’re missing commas, maybe from format_line.

I haven’t tried to reproduce it locally, but given it’s across all
macOS and Ubuntu versions I would be surprised if I couldn’t.

> makeobjops.awk doesn't have any of the issues that I know are minor changes
> in awk. I'll add it to the list of things to look into, though.

On what timeline? If not soon, can we please revert the import as it’s
breaking important things and thus not ready for the tree?

Jess

> I also broke the Jenkins CI run, but not 'make check' for reasons I don't
> understand.
> 
> Warner





Re: git: 9eecef052155 - main - Add an Armv8 rndr random number provider

2023-11-15 Thread Jessica Clarke
On 15 Nov 2023, at 18:27, Jessica Clarke  wrote:
> 
> On 15 Nov 2023, at 18:12, Andrew Turner  wrote:
>> 
>> The branch main has been updated by andrew:
>> 
>> URL: 
>> https://cgit.FreeBSD.org/src/commit/?id=9eecef052155646fbc5f8f533b952b372572d06a
>> 
>> commit 9eecef052155646fbc5f8f533b952b372572d06a
>> Author: Andrew Turner 
>> AuthorDate: 2023-11-15 17:42:02 +
>> Commit: Andrew Turner 
>> CommitDate: 2023-11-15 18:05:08 +
>> 
>>   Add an Armv8 rndr random number provider
>> 
>>   Armv8.5 adds an optional random number generator. This is implemented
>>   as two special registers one to read a random number, the other to
>>   re-seed the entropy pool before reading a random number. Both registers
>>   will set the condition flags to tell the caller they can't produce a
>>   random number in a reasonable amount of time.
>> 
>>   Without a signal to reseed the entropy pool use the latter register
>>   to provide random numbers to the kernel pool. If at a later time we
>>   had a way to tell the provider if it needs to reseed or not we could
>>   use the former.
>> 
>>   On an Amazon AWS Graviton3 VM this never failed, however this may not
>>   be the case on low end CPUs so retry reading the random number 10 times
>>   before returning an error.
>> 
>>   Reviewed by:imp, delphij (csprng)
>>   Sponsored by:   The FreeBSD Foundation
>>   Sponsored by:   Arm Ltd
>>   Differential Revision:  https://reviews.freebsd.org/D35411
>> ---
>> sys/arm64/conf/std.dev   |   1 +
>> sys/conf/files.arm64 |   2 +
>> sys/dev/random/armv8rng.c| 135 
>> +++
>> sys/dev/random/random_harvestq.c |   1 +
>> sys/modules/Makefile |   2 +
>> sys/modules/armv8_rng/Makefile   |  11 
>> sys/sys/random.h |   1 +
>> 7 files changed, 153 insertions(+)
>> 
>> diff --git a/sys/arm64/conf/std.dev b/sys/arm64/conf/std.dev
>> index 74d2407e0aec..0ebf2e775b11 100644
>> --- a/sys/arm64/conf/std.dev
>> +++ b/sys/arm64/conf/std.dev
>> @@ -53,6 +53,7 @@ device vt_simplefb
>> 
>> # Pseudo devices.
>> device crypto # core crypto support
>> +device armv8_rng # Armv8.5 rndr RNG
>> device loop # Network loopback
>> device ether # Ethernet support
>> device vlan # 802.1Q VLAN support
>> diff --git a/sys/conf/files.arm64 b/sys/conf/files.arm64
>> index 38b9e40463eb..9ccead6a98e1 100644
>> --- a/sys/conf/files.arm64
>> +++ b/sys/conf/files.arm64
>> @@ -379,6 +379,8 @@ dev/psci/psci.c standard
>> dev/psci/smccc_arm64.S standard
>> dev/psci/smccc.c standard
>> 
>> +dev/random/armv8rng.c optional armv8_rng !random_loadable
>> +
>> dev/safexcel/safexcel.c optional safexcel fdt
>> 
>> dev/sdhci/sdhci_xenon.c optional sdhci_xenon sdhci
>> diff --git a/sys/dev/random/armv8rng.c b/sys/dev/random/armv8rng.c
>> new file mode 100644
>> index ..3cca42a5bbf3
>> --- /dev/null
>> +++ b/sys/dev/random/armv8rng.c
>> @@ -0,0 +1,135 @@
>> +/*-
>> + * Copyright (c) 2022 The FreeBSD Foundation
>> + *
>> + * This software was developed by Andrew Turner under sponsorship from
>> + * the FreeBSD Foundation.
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + * 1. Redistributions of source code must retain the above copyright
>> + *notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + *notice, this list of conditions and the following disclaimer in the
>> + *documentation and/or other materials provided with the distribution.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
>> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
>> PURPOSE
>> + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
>> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
>> CONSEQUENTIAL
>> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
>> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
>> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 
>> STRICT
>> + * LIABILITY, OR TORT (INCLUDING NEGLIGE

Re: git: 99132daf6f70 - main - rc.d/ldconfig: Prepend rtld stdlib paths to ldconfig(32)_paths

2023-11-16 Thread Jessica Clarke
On 16 Nov 2023, at 12:44, Dima Panov  wrote:
> 
> Moin-moin!
> 
> 
> This cause some errors while running, at least on aarch64, host and poudriere 
> jail
> 
> 
> # service ldconfig restart
> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 
> /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/e2fsprogs 
> /usr/local/lib/mysql /usr/local/lib/perl5/5.38/mach/CORE /usr/local/llvm16/lib
> ELF binary type "9" not known.
> eval: /libexec/ld-elf32.so.1: Exec format error
> 32-bit compatibility ldconfig path: /usr/lib32

Yeah this breaks if the kernel and/or hardware don’t support 32-bit
compat (not uncommon on modern Arm hardware).

Also, parsing the human-readable output of ld-elf.so.1 -v to determine
the path seems wrong and fragile. Given the above problem I think this
should just be reverted, but if we instead want to press ahead with
something like this (with suitable handling of this case) then we
should really have ld-elf.so.1 produce machine-readable output (which
could just be the space-separated string) for use the rc script, not go
mangling -v’s output. But I really don’t see the issue with putting the
paths in the script...

Jess

> On 14.11.2023 02:39, Konstantin Belousov wrote:
>> The branch main has been updated by kib:
>> URL: 
>> https://cgit.FreeBSD.org/src/commit/?id=99132daf6f70cb0cc969c555d3612547fa3cf1db
>> commit 99132daf6f70cb0cc969c555d3612547fa3cf1db
>> Author: John W. O'Brien 
>> AuthorDate: 2023-11-12 22:45:27 +
>> Commit: Konstantin Belousov 
>> CommitDate: 2023-11-13 23:39:17 +
>> rc.d/ldconfig: Prepend rtld stdlib paths to ldconfig(32)_paths
>>  Ensure that ldconfig-managed elf and elf32 hints always include
>> the standard library paths that are known independently to rtld.
>>  PR: 275031
>> Reviewed by:kib
>> MFC after:  2 weeks
>> Sponsored by:   Saltant Solutions LLC
>> Differential Revision:  https://reviews.freebsd.org/D42557
>> ---
>>  libexec/rc/rc.d/ldconfig | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>> diff --git a/libexec/rc/rc.d/ldconfig b/libexec/rc/rc.d/ldconfig
>> index 178a8a987be4..ecbbca210ea0 100755
>> --- a/libexec/rc/rc.d/ldconfig
>> +++ b/libexec/rc/rc.d/ldconfig
>> @@ -22,7 +22,7 @@ ldconfig_start()
>>   ldconfig=${ldconfig_command}
>>   checkyesno ldconfig_insecure && _ins="-i"
>>   if [ -x "${ldconfig_command}" ]; then
>> - _LDC="/lib /usr/lib"
>> + _LDC=$(/libexec/ld-elf.so.1 -v | sed -n -e '/^Default lib path /s///p' | 
>> tr : ' ')
>>   for i in ${ldconfig_local_dirs}; do
>>   if [ -d "${i}" ]; then
>>   _files=`find ${i} -type f`
>> @@ -52,6 +52,9 @@ ldconfig_start()
>>   fi
>>   done
>>   _LDC=""
>> + if [ -x /libexec/ld-elf32.so.1 ]; then
>> + _LDC=$(/libexec/ld-elf32.so.1 -v | sed -n -e '/^Default lib path /s///p' | 
>> tr : ' ')
>> + fi
>>   for i in ${ldconfig32_paths}; do
>>   if [ -r "${i}" ]; then
>>   _LDC="${_LDC} ${i}"
> 
> -- 
> Sincerely,
> Dima (flu...@freebsd.org, https://t.me/FluffyBSD)
> (desktop, kde, x11, office, ports-secteam)@FreeBSD team




Re: git: accfb4cc9346 - main - genoffset.sh: stop using a temporary file

2023-11-16 Thread Jessica Clarke
On 16 Nov 2023, at 15:07, Jonathan T. Looney  wrote:
> 
> The branch main has been updated by jtl:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=accfb4cc9346b23f6d6383dfc98d2c97ae18ce0d
> 
> commit accfb4cc9346b23f6d6383dfc98d2c97ae18ce0d
> Author: Jonathan T. Looney 
> AuthorDate: 2023-11-16 15:02:32 +
> Commit: Jonathan T. Looney 
> CommitDate: 2023-11-16 15:02:32 +
> 
>genoffset.sh: stop using a temporary file
> 
>Instead, use a here document for the input. This allows us to run the
>while loop in the main script so we can build the list of asserts in
>a shell variable. We then print out the list of asserts at the end of
>the loop.
> 
>Reviewed by:imp
>Sponsored by:   Netflix
>Differential Revision:  https://reviews.freebsd.org/D42407
> ---
> sys/kern/genoffset.sh | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/sys/kern/genoffset.sh b/sys/kern/genoffset.sh
> index fda27998ca79..c974a7d52e8c 100644
> --- a/sys/kern/genoffset.sh
> +++ b/sys/kern/genoffset.sh
> @@ -35,16 +35,13 @@ usage()
> 
> work()
> (
> -local last off x1 x2 x3 struct field type lastoff lasttype
> +local last off x1 x2 x3 struct field type lastoff lasttype asserts
> 
> echo "#ifndef _OFFSET_INC_"
> echo "#define _OFFSET_INC_"
> echo "#if !defined(GENOFFSET) && (!defined(KLD_MODULE) || 
> defined(KLD_TIED))"
> last=
> -temp=$(mktemp -d genoffset.XX)
> -trap "rm -rf ${temp}" EXIT
> -# Note: we need to print symbol values in decimal so the numeric sort 
> works
> -${NM:='nm'} ${NMFLAGS} -t d "$1" | grep __assym_offset__ | sed -e 's/__/ 
> /g' | sort -k 4 -k 1 -n |
> +asserts=
> while read off x1 x2 struct field type x3; do
> off=$(echo "$off" | sed -E 's/^0+//')
> if [ "$last" != "$struct" ]; then
> @@ -60,12 +57,14 @@ work()
> printf "%b" "\t${type}\t${field};\n"
> lastoff="$off"
> lasttype="$type"
> - echo "_SA(${struct}, ${field}, ${off});" >> "$temp/asserts"
> -done
> + asserts="${asserts}_SA(${struct}, ${field}, ${off});\n"
> +done < +$(${NM:='nm'} ${NMFLAGS} -t d "$1" | grep __assym_offset__ | sed -e 's/__/ 
> /g' | sort -k 4 -k 1 -n)
> +EOT
> echo "};"
> echo "#define _SA(s,f,o) _Static_assert(__builtin_offsetof(struct s ## 
> _lite, f) == o, \\"
> printf '\t"struct "#s"_lite field "#f" not at offset "#o)\n'
> -cat "$temp/asserts"
> +echo -e "${asserts}\c"

This isn’t POSIX, and isn’t supported by macOS’s sh, so breaks the
build there. Please fix or revert promptly.

Jess

> echo "#undef _SA"
> echo "#endif"
> echo "#endif"




Re: git: 2d486ba15f33 - main - pkgbase: Move bectl to the runtime package

2021-01-05 Thread Jessica Clarke
> On 5 Jan 2021, at 15:54, Rodney W. Grimes  wrote:
> 
>> On Mon, 4 Jan 2021 12:58:58 -0800 (PST)
>> "Rodney W. Grimes"  wrote:
>> 
 On Mon, 4 Jan 2021 12:49:19 -0800 (PST)
 "Rodney W. Grimes"  wrote:
 
>> The branch main has been updated by manu:
>> 
>> URL: 
>> https://cgit.FreeBSD.org/src/commit/?id=2d486ba15f3367072d631ee588192ef46687fa4b
>> 
>> commit 2d486ba15f3367072d631ee588192ef46687fa4b
>> Author: Emmanuel Vadot 
>> AuthorDate: 2020-12-21 15:00:02 +
>> Commit: Emmanuel Vadot 
>> CommitDate: 2021-01-04 15:17:12 +
>> 
>>pkgbase: Move bectl to the runtime package
>> 
>>runtime contain what is needed to boot in single user and repair a
>>system, bectl could be handy to have in this situation.
> 
> I would think it belongs in the zfs package,
> as unless you have zfs you do not need bectrl.
 
 There is no zfs package.
>>> 
>>> I would consider that an oversight.
>> 
>> I don't. We don't have a ufs package for example.
> 
> My understanding of the "big idea" of pkg base is to fine
> grain feature install/removal, and I would consider support
> for things like nfs, ufs, zfs to be along those lines
> of fine grain.

We could do that. I don't know enough to take a view on whether that's
a good idea or not. But I do think it's more important to get something
working and rolled-out than spend another 5 years iterating on it to
try and achieve perfection. Things that make pkgbase unusable for
currently-supported use cases should obviously be fixed, but adding
finer-grained packages can come later (or now if you provide tested
patches!).

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 613a08cfa2e0 - main - rtld: map without PROT_EXEC for relocation

2021-01-05 Thread Jessica Clarke
On 5 Jan 2021, at 15:57, Ed Maste  wrote:
> diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c
> index 27262ab9dbc5..7b8bfba84d7d 100644
> --- a/libexec/rtld-elf/rtld.c
> +++ b/libexec/rtld-elf/rtld.c
> @@ -2982,7 +2982,8 @@ reloc_textrel_prot(Obj_Entry *obj, bool before)
>   base = obj->relocbase + trunc_page(ph->p_vaddr);
>   sz = round_page(ph->p_vaddr + ph->p_filesz) -
>   trunc_page(ph->p_vaddr);
> - prot = convert_prot(ph->p_flags) | (before ? PROT_WRITE : 0);
> + prot = before ? (PROT_READ | PROT_WRITE) :
> + convert_prot(ph->p_flags);
>   if (mprotect(base, sz, prot) == -1) {
>   _rtld_error("%s: Cannot write-%sable text segment: %s",
>   obj->path, before ? "en" : "dis",

This error message could perhaps be improved now that both W and X are
varying? As it stands it reads like the code used to function.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 92cf602e3809 - main - Copy strcasestr.c from libc to libkern.

2021-01-07 Thread Jessica Clarke
On 7 Jan 2021, at 23:20, Vladimir Kondratyev  wrote:
> +#include 
> +#include 
> +#include "xlocale_private.h"
> +
> +/*
> + * Find the first occurrence of find in s, ignore case.
> + */
> +char *
> +strcasestr_l(const char *s, const char *find, locale_t locale)

Locales in the kernel? This feels wrong.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 6733401935f8 - main - nvmecontrol: add device self-test op and log page

2021-01-08 Thread Jessica Clarke
On 8 Jan 2021, at 17:29, Chuck Tuffli  wrote:
> diff --git a/sys/dev/nvme/nvme.h b/sys/dev/nvme/nvme.h
> index 3c159b1fd0fc..67d02ba73fd8 100644
> --- a/sys/dev/nvme/nvme.h
> +++ b/sys/dev/nvme/nvme.h
> @@ -1396,6 +1396,28 @@ struct nvme_command_effects_page {
> _Static_assert(sizeof(struct nvme_command_effects_page) == 4096,
> "bad size for nvme_command_effects_page");
> 
> +struct nvme_device_self_test_page {
> + uint8_t curr_operation;
> + uint8_t curr_compl;
> + uint8_t rsvd2[2];
> + struct {
> + uint8_t status;
> + uint8_t segment_num;
> + uint8_t valid_diag_info;
> + uint8_t rsvd3;
> + uint64_tpoh;
> + uint32_tnsid;
> + /* Define as an array to simplify alignment issues */
> + uint8_t failing_lba[8];
> + uint8_t status_code_type;
> + uint8_t status_code;
> + uint8_t vendor_specific[2];
> + } __packed result[20];
> +} __packed __aligned(4);
> +
> +_Static_assert(sizeof(struct nvme_device_self_test_page) == 564,
> +"bad size for nvme_device_self_test_page");
> +
> struct nvme_res_notification_page {
>   uint64_tlog_page_count;
>   uint8_t log_page_type;
> @@ -2016,4 +2038,21 @@ void   nvme_resv_status_ext_swapbytes(struct 
> nvme_resv_status_ext *s __unused,
> #endif
> }
> 
> +static inline void
> +nvme_device_self_test_swapbytes(struct nvme_device_self_test_page *s 
> __unused)
> +{
> +#if _BYTE_ORDER != _LITTLE_ENDIAN
> + uint64_t failing_lba;
> + uint32_t r;
> +
> + for (r = 0; r < 20; r++) {
> + s->result[r].poh = le64toh(s->result[r].poh);
> + s->result[r].nsid = le32toh(s->result[r].nsid);
> + /* Unaligned 64-bit loads fail on some architectures */
> + memcpy(&failing_lba, s->result[r].failing_lba, 
> sizeof(failing_lba));
> + failing_lba = le64toh(failing_lba);
> + memcpy(s->result[r].failing_lba, &failing_lba, 
> sizeof(failing_lba));
> + }
> +#endif
> +}
> #endif /* __NVME_H__ */

Hi,
This broke powerpc and powerpc64:

In file included from ioctl.c:33:
In file included from /home/jrtc27/src/sys/./cam/scsi/scsi_pass.h:35:
In file included from /home/jrtc27/src/sys/cam/cam_ccb.h:46:
In file included from /home/jrtc27/src/sys/cam/nvme/nvme_all.h:33:
/home/jrtc27/src/sys/dev/nvme/nvme.h:2052:3: error: implicitly declaring 
library function 'memcpy' with type 'void *(void *, const void *, unsigned 
long)' [-Werror,-Wimplicit-function-declaration]
memcpy(&failing_lba, s->result[r].failing_lba, 
sizeof(failing_lba));
^
/home/jrtc27/src/sys/dev/nvme/nvme.h:2052:3: note: include the header 
 or explicitly provide a declaration for 'memcpy'
1 error generated.
--- ioctl.o ---
*** [ioctl.o] Error code 1

make[7]: stopped in /home/jrtc27/src/lib/libsysdecode
1 error

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: f222a6b88614 - main - dtrace: Fix /"string" == NULL/ comparisons using an uninitialized value.

2021-01-08 Thread Jessica Clarke
On 9 Jan 2021, at 02:05, Mateusz Guzik  wrote:
> 
> tinderbox fails to build riscv kernels with:
> 
> In file included from
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:18434:
> /usr/src/sys/cddl/dev/dtrace/riscv/dtrace_isa.c:155:13: error:
> variable 'oldfp' is uninitialized when used here
> [-Werror,-Wuninitialized]
>if (fp == oldfp) {
>  ^
> /usr/src/sys/cddl/dev/dtrace/riscv/dtrace_isa.c:122:17: note:
> initialize the variable 'oldfp' to silence this warning
>uintptr_t oldfp;
>   ^
>= 0
> 1 error generated.
> 
> which stems from the Makefile change.

https://reviews.freebsd.org/D28054

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: facdd1cd2045 - main - cgem: add 64-bit support

2021-01-10 Thread Jessica Clarke
On 10 Jan 2021, at 20:53, Mitchell Horne  wrote:
> diff --git a/sys/dev/cadence/if_cgem.c b/sys/dev/cadence/if_cgem.c
> index 3c5277452469..77337e977dcc 100644
> --- a/sys/dev/cadence/if_cgem.c
> +++ b/sys/dev/cadence/if_cgem.c
> @@ -77,6 +77,14 @@ __FBSDID("$FreeBSD$");
> #include 
> #include 
> 
> +#ifdef EXT_RESOURCES
> +#include 
> +#endif
> +
> +#if INTPTR_MAX == INT64_MAX
> +#define CGEM64
> +#endif

This isn't going to work with CHERI. Perhaps a BUS_SPACE_MAXADDR check,
or SIZE_MAX? The former is probably preferable for PAE systems.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: facdd1cd2045 - main - cgem: add 64-bit support

2021-01-10 Thread Jessica Clarke
On 10 Jan 2021, at 21:31, Konstantin Belousov  wrote:
> On Sun, Jan 10, 2021 at 09:17:48PM +0000, Jessica Clarke wrote:
>> On 10 Jan 2021, at 20:53, Mitchell Horne  wrote:
>>> diff --git a/sys/dev/cadence/if_cgem.c b/sys/dev/cadence/if_cgem.c
>>> index 3c5277452469..77337e977dcc 100644
>>> --- a/sys/dev/cadence/if_cgem.c
>>> +++ b/sys/dev/cadence/if_cgem.c
>>> @@ -77,6 +77,14 @@ __FBSDID("$FreeBSD$");
>>> #include 
>>> #include 
>>> 
>>> +#ifdef EXT_RESOURCES
>>> +#include 
>>> +#endif
>>> +
>>> +#if INTPTR_MAX == INT64_MAX
>>> +#define CGEM64
>>> +#endif
>> 
>> This isn't going to work with CHERI. Perhaps a BUS_SPACE_MAXADDR check,
>> or SIZE_MAX? The former is probably preferable for PAE systems.
> 
> Wouldn't it be spelled as __LP64__ ?

It shouldn't be, because the P stands for pointer(s), which we make
128-bit, though in practice for compatibility we have a hack to define
it anyway (but the compiler *won't*, it's in bsd.cpu.mk or similar).
Only the integer addresses are 128-bit.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: facdd1cd2045 - main - cgem: add 64-bit support

2021-01-10 Thread Jessica Clarke
On 10 Jan 2021, at 21:33, Jessica Clarke  wrote:
> On 10 Jan 2021, at 21:31, Konstantin Belousov  wrote:
>> On Sun, Jan 10, 2021 at 09:17:48PM +, Jessica Clarke wrote:
>>> On 10 Jan 2021, at 20:53, Mitchell Horne  wrote:
>>>> diff --git a/sys/dev/cadence/if_cgem.c b/sys/dev/cadence/if_cgem.c
>>>> index 3c5277452469..77337e977dcc 100644
>>>> --- a/sys/dev/cadence/if_cgem.c
>>>> +++ b/sys/dev/cadence/if_cgem.c
>>>> @@ -77,6 +77,14 @@ __FBSDID("$FreeBSD$");
>>>> #include 
>>>> #include 
>>>> 
>>>> +#ifdef EXT_RESOURCES
>>>> +#include 
>>>> +#endif
>>>> +
>>>> +#if INTPTR_MAX == INT64_MAX
>>>> +#define CGEM64
>>>> +#endif
>>> 
>>> This isn't going to work with CHERI. Perhaps a BUS_SPACE_MAXADDR check,
>>> or SIZE_MAX? The former is probably preferable for PAE systems.
>> 
>> Wouldn't it be spelled as __LP64__ ?
> 
> It shouldn't be, because the P stands for pointer(s), which we make
> 128-bit, though in practice for compatibility we have a hack to define
> it anyway (but the compiler *won't*, it's in bsd.cpu.mk or similar).
> Only the integer addresses are 128-bit.

As for the original comment about the diff, I stand corrected; it's
using MAX not SIZE, so will work on CHERI.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: facdd1cd2045 - main - cgem: add 64-bit support

2021-01-10 Thread Jessica Clarke
On 10 Jan 2021, at 21:41, Konstantin Belousov  wrote:
> On Sun, Jan 10, 2021 at 09:33:16PM +0000, Jessica Clarke wrote:
>> On 10 Jan 2021, at 21:31, Konstantin Belousov  wrote:
>>> On Sun, Jan 10, 2021 at 09:17:48PM +0000, Jessica Clarke wrote:
>>>> On 10 Jan 2021, at 20:53, Mitchell Horne  wrote:
>>>>> diff --git a/sys/dev/cadence/if_cgem.c b/sys/dev/cadence/if_cgem.c
>>>>> index 3c5277452469..77337e977dcc 100644
>>>>> --- a/sys/dev/cadence/if_cgem.c
>>>>> +++ b/sys/dev/cadence/if_cgem.c
>>>>> @@ -77,6 +77,14 @@ __FBSDID("$FreeBSD$");
>>>>> #include 
>>>>> #include 
>>>>> 
>>>>> +#ifdef EXT_RESOURCES
>>>>> +#include 
>>>>> +#endif
>>>>> +
>>>>> +#if INTPTR_MAX == INT64_MAX
>>>>> +#define CGEM64
>>>>> +#endif
>>>> 
>>>> This isn't going to work with CHERI. Perhaps a BUS_SPACE_MAXADDR check,
>>>> or SIZE_MAX? The former is probably preferable for PAE systems.
>>> 
>>> Wouldn't it be spelled as __LP64__ ?
>> 
>> It shouldn't be, because the P stands for pointer(s), which we make
>> 128-bit, though in practice for compatibility we have a hack to define
>> it anyway (but the compiler *won't*, it's in bsd.cpu.mk or similar).
>> Only the integer addresses are 128-bit.
> 
> I have no idea about CHERI, I mean how this statement should be handled
> for FreeBSD.

Well, ideally in a way that works for FreeBSD and CHERI. This one
happens to do that, though it doesn't feel very idiomatic, and a
comparison against SIZE_MAX or BUS_SPACE_MAXADDR would seem more
accurate (depending on the behaviour you want for PAE systems). FreeBSD
*can* use __LP64__ but it causes pain for us downstream so we prefer
people to be more specific in what they mean (i.e., do you care about
the size of the address space or the size of the representation of
pointers).

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 16079c7233be - main - hid: quiet -Wswitch

2021-01-11 Thread Jessica Clarke
On 11 Jan 2021, at 19:14, Vladimir Kondratyev  wrote:
> On 11.01.2021 21:03, John Baldwin wrote:
>> On 1/10/21 9:54 PM, Ryan Libby wrote:
>>> The branch main has been updated by rlibby:
>>> 
>>> URL: 
>>> https://cgit.FreeBSD.org/src/commit/?id=16079c7233be8bd6c88e3421a70c7ca87cfea370
>>> 
>>> commit 16079c7233be8bd6c88e3421a70c7ca87cfea370
>>> Author: Ryan Libby 
>>> AuthorDate: 2021-01-11 05:53:15 +
>>> Commit: Ryan Libby 
>>> CommitDate: 2021-01-11 05:53:15 +
>>> 
>>>hid: quiet -Wswitch
>>> 
>>>Gcc builds complained that not all switch cases are handled.  Add
>>>default cases to appease gcc.
>>> 
>>>Reviewed by:hselasky (previous version), wulf
>>>Sponsored by:   Dell EMC Isilon
>>>Differential Revision:  https://reviews.freebsd.org/D28082
>> 
>> If these cases are never reachable, then I think '__assert_unreachable()'
>> is preferred to a plain break.
>> 
> These cases are reachable. They are NOP steps of state machine.

How many states are there? It might be better to document that using an
explicit set of case labels that just immediately break (and then
-Wswitch will help you in future in case you ever forget to update one
of the switch statements). Where possible -Wswitch is best fixed, not
silenced with default, though there are times when the latter is
preferable.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 3b15beb30b3b - main - Implement malloc_domainset_aligned(9).

2021-01-18 Thread Jessica Clarke
On 18 Jan 2021, at 21:19, Konstantin Belousov  wrote:
> On Mon, Jan 18, 2021 at 08:45:43PM +, Alexander V. Chernikov wrote:
>> 17.01.2021, 17:30, "Konstantin Belousov" :
>>> The branch main has been updated by kib:
>>> 
>>> URL: 
>>> https://cgit.FreeBSD.org/src/commit/?id=3b15beb30b3b4ba17bae3d1d43c8c04ff862bb57
>>> 
>>> commit 3b15beb30b3b4ba17bae3d1d43c8c04ff862bb57
>>> Author: Konstantin Belousov 
>>> AuthorDate: 2021-01-14 03:59:34 +
>>> Commit: Konstantin Belousov 
>>> CommitDate: 2021-01-17 17:29:05 +
>>> 
>>> Implement malloc_domainset_aligned(9).
>> Hi Kostik,
>> 
>> This change makes my vm panic in usb code. No dump, as dumpdev not mounted 
>> yet.
>> 
>> Note: the below lines have been OCR'ed, so there may be some errors.
>> 
>> Root mount waiting for: CAM usbus0 usbus1
>> panic: malloc_domainset_aligned: result not aligned 0xf8000551ca80 size 
>> 0x180 align 0x100
> 
> Try this.
> 
> ...
>   if (size < align)
> - size = align;
> - res = malloc_domainset(size, mtp, ds, flags);
> + asize = align;
> + else if (!powerof2(size))
> + asize = roundup2(size, align);
> + else
> + asize = size;

Why not just `asize = roundup2(size, align)`? It's only 3 instructions
(4 on Clang due to a missed combine) on amd64 and I'd be very surprised
if the branching version were faster even in the fast path case. Plus
it's much easier to read; currently it looks like there's something
unusual going on but there really isn't.

https://godbolt.org/z/rv6qs7 FWIW

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: fbe0c4f4c7f4 - main - virtio: Add modern (v1) virtqueue support

2021-01-18 Thread Jessica Clarke
Hi Bryan,
Neither of my review comments from 2.5 weeks ago were addressed.

Jess

On 19 Jan 2021, at 05:08, Bryan Venteicher  wrote:
> 
> The branch main has been updated by bryanv:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=fbe0c4f4c7f4474def7b041c29c1e2facf2af08b
> 
> commit fbe0c4f4c7f4474def7b041c29c1e2facf2af08b
> Author: Bryan Venteicher 
> AuthorDate: 2021-01-19 04:55:23 +
> Commit: Bryan Venteicher 
> CommitDate: 2021-01-19 04:55:23 +
> 
>virtio: Add modern (v1) virtqueue support
> 
>This only supports the legacy virtqueue format that is now called
>"Split Virtqueues". Support for the new "Packed Virtqueues" described
>in v1.1 is left for a later date.
> 
>Reviewed by: grehan (mentor)
>Differential Revision: https://reviews.freebsd.org/D27857
> ---
> sys/dev/virtio/virtqueue.c | 141 -
> sys/dev/virtio/virtqueue.h |   2 -
> 2 files changed, 75 insertions(+), 68 deletions(-)
> 
> diff --git a/sys/dev/virtio/virtqueue.c b/sys/dev/virtio/virtqueue.c
> index da6e7bf89fd5..14c2088b70a8 100644
> --- a/sys/dev/virtio/virtqueue.c
> +++ b/sys/dev/virtio/virtqueue.c
> @@ -57,19 +57,15 @@ __FBSDID("$FreeBSD$");
> 
> struct virtqueue {
>   device_t vq_dev;
> - char vq_name[VIRTQUEUE_MAX_NAME_SZ];
>   uint16_t vq_queue_index;
>   uint16_t vq_nentries;
>   uint32_t vq_flags;
> -#define  VIRTQUEUE_FLAG_INDIRECT  0x0001
> -#define  VIRTQUEUE_FLAG_EVENT_IDX 0x0002
> +#define  VIRTQUEUE_FLAG_MODERN0x0001
> +#define  VIRTQUEUE_FLAG_INDIRECT  0x0002
> +#define  VIRTQUEUE_FLAG_EVENT_IDX 0x0004
> 
> - bus_size_t   vq_notify_offset;
> - int  vq_alignment;
> - int  vq_ring_size;
> - void*vq_ring_mem;
>   int  vq_max_indirect_size;
> - int  vq_indirect_mem_size;
> + bus_size_t   vq_notify_offset;
>   virtqueue_intr_t*vq_intrhand;
>   void*vq_intrhand_arg;
> 
> @@ -88,6 +84,12 @@ struct virtqueue {
>*/
>   uint16_t vq_used_cons_idx;
> 
> + void*vq_ring_mem;
> + int  vq_indirect_mem_size;
> + int  vq_alignment;
> + int  vq_ring_size;
> + char vq_name[VIRTQUEUE_MAX_NAME_SZ];
> +
>   struct vq_desc_extra {
>   void  *cookie;
>   struct vring_desc *indirect;
> @@ -135,17 +137,13 @@ static int  vq_ring_must_notify_host(struct 
> virtqueue *);
> static void   vq_ring_notify_host(struct virtqueue *);
> static void   vq_ring_free_chain(struct virtqueue *, uint16_t);
> 
> -uint64_t
> -virtqueue_filter_features(uint64_t features)
> -{
> - uint64_t mask;
> -
> - mask = (1 << VIRTIO_TRANSPORT_F_START) - 1;
> - mask |= VIRTIO_RING_F_INDIRECT_DESC;
> - mask |= VIRTIO_RING_F_EVENT_IDX;
> -
> - return (features & mask);
> -}
> +#define vq_modern(_vq)   (((_vq)->vq_flags & 
> VIRTQUEUE_FLAG_MODERN) != 0)
> +#define vq_htog16(_vq, _val) virtio_htog16(vq_modern(_vq), _val)
> +#define vq_htog32(_vq, _val) virtio_htog32(vq_modern(_vq), _val)
> +#define vq_htog64(_vq, _val) virtio_htog64(vq_modern(_vq), _val)
> +#define vq_gtoh16(_vq, _val) virtio_gtoh16(vq_modern(_vq), _val)
> +#define vq_gtoh32(_vq, _val) virtio_gtoh32(vq_modern(_vq), _val)
> +#define vq_gtoh64(_vq, _val) virtio_gtoh64(vq_modern(_vq), _val)
> 
> int
> virtqueue_alloc(device_t dev, uint16_t queue, uint16_t size,
> @@ -193,6 +191,8 @@ virtqueue_alloc(device_t dev, uint16_t queue, uint16_t 
> size,
>   vq->vq_intrhand = info->vqai_intr;
>   vq->vq_intrhand_arg = info->vqai_intr_arg;
> 
> + if (VIRTIO_BUS_WITH_FEATURE(dev, VIRTIO_F_VERSION_1) != 0)
> + vq->vq_flags |= VIRTQUEUE_FLAG_MODERN;
>   if (VIRTIO_BUS_WITH_FEATURE(dev, VIRTIO_RING_F_EVENT_IDX) != 0)
>   vq->vq_flags |= VIRTQUEUE_FLAG_EVENT_IDX;
> 
> @@ -297,8 +297,8 @@ virtqueue_init_indirect_list(struct virtqueue *vq,
>   bzero(indirect, vq->vq_indirect_mem_size);
> 
>   for (i = 0; i < vq->vq_max_indirect_size - 1; i++)
> - indirect[i].next = i + 1;
> - indirect[i].next = VQ_RING_DESC_CHAIN_END;
> + indirect[i].next = vq_gtoh16(vq, i + 1);
> + indirect[i].next = vq_gtoh16(vq, VQ_RING_DESC_CHAIN_END);
> }
> 
> int
> @@ -396,6 +396,7 @@ virtqueue_used_paddr(struct virtqueue *vq)
> uint16_t
> virtqueue_index(struct virtqueue *vq)
> {
> +
>   return (vq->vq_queue_index);
> }
> 
> @@ -444,7 +445,7 @@ virtqueue_nused(struct virtqueue *vq)
> {
>   uint16_t used_idx, nused;
> 
> - used_idx = vq->vq_ring.used->idx;
> + used_idx = vq_htog16(vq, vq->vq_ring.used->idx);

Re: git: 9da9560c4dd3 - main - virtio: Add VirtIO PCI modern (V1) support

2021-01-18 Thread Jessica Clarke
Hi Bryan,
I had a couple of unaddressed review comments still unresolved.

Jess

> On 19 Jan 2021, at 05:08, Bryan Venteicher  wrote:
> 
> The branch main has been updated by bryanv:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=9da9560c4dd3556519cd391a04f0db157dc3c295
> 
> commit 9da9560c4dd3556519cd391a04f0db157dc3c295
> Author: Bryan Venteicher 
> AuthorDate: 2021-01-19 04:55:23 +
> Commit: Bryan Venteicher 
> CommitDate: 2021-01-19 04:55:23 +
> 
>virtio: Add VirtIO PCI modern (V1) support
> 
>Use the existing legacy PCI driver as the basis for shared code
>between the legacy and modern PCI drivers. The existing virtio_pci
>kernel module will contain both the legacy and modern drivers.
> 
>Changes to the virtqueue and each device driver (network, block, etc)
>for V1 support come in later commits.
> 
>Update the MMIO driver to reflect the VirtIO bus method changes, but
>the modern compliance can be improved on later.
> 
>Note that the modern PCI driver requires bus_map_resource() to be
>implemented, which is not the case on all archs.
> 
>The hw.virtio.pci.transitional tunable default value is zero so
>transitional devices will continue to be driven via the legacy
>driver.
> 
>Reviewed by: grehan (mentor)
>Differential Revision: https://reviews.freebsd.org/D27856
> ---
> sys/conf/files |3 +
> sys/dev/virtio/mmio/virtio_mmio.c  |   23 +-
> sys/dev/virtio/pci/virtio_pci.c| 1297 +
> sys/dev/virtio/pci/virtio_pci.h|  173 ++--
> sys/dev/virtio/pci/virtio_pci_if.m |   71 ++
> sys/dev/virtio/pci/virtio_pci_legacy.c |  733 ++
> sys/dev/virtio/pci/virtio_pci_legacy_var.h |   78 ++
> sys/dev/virtio/pci/virtio_pci_modern.c | 1448 
> sys/dev/virtio/pci/virtio_pci_modern_var.h |  135 +++
> sys/dev/virtio/pci/virtio_pci_var.h|   55 ++
> sys/dev/virtio/virtio.c|   76 +-
> sys/dev/virtio/virtio.h|8 +
> sys/dev/virtio/virtio_bus_if.m |   11 +
> sys/dev/virtio/virtio_endian.h |  106 ++
> sys/dev/virtio/virtqueue.c |   10 +-
> sys/dev/virtio/virtqueue.h |4 +-
> sys/modules/virtio/pci/Makefile|5 +-
> 17 files changed, 3292 insertions(+), 944 deletions(-)
> 
> diff --git a/sys/conf/files b/sys/conf/files
> index e641b79d9c46..79f3b7ca54e6 100644
> --- a/sys/conf/files
> +++ b/sys/conf/files
> @@ -3457,6 +3457,9 @@ dev/virtio/virtqueue.c  optional
> virtio
> dev/virtio/virtio_bus_if.moptionalvirtio
> dev/virtio/virtio_if.moptionalvirtio
> dev/virtio/pci/virtio_pci.c   optionalvirtio_pci
> +dev/virtio/pci/virtio_pci_if.m   optionalvirtio_pci
> +dev/virtio/pci/virtio_pci_legacy.c   optionalvirtio_pci
> +dev/virtio/pci/virtio_pci_modern.c   optionalvirtio_pci
> dev/virtio/mmio/virtio_mmio.c optionalvirtio_mmio
> dev/virtio/mmio/virtio_mmio_acpi.coptionalvirtio_mmio acpi
> dev/virtio/mmio/virtio_mmio_fdt.c optionalvirtio_mmio fdt
> diff --git a/sys/dev/virtio/mmio/virtio_mmio.c 
> b/sys/dev/virtio/mmio/virtio_mmio.c
> index bb5d84754f09..694d2a232fdd 100644
> --- a/sys/dev/virtio/mmio/virtio_mmio.c
> +++ b/sys/dev/virtio/mmio/virtio_mmio.c
> @@ -84,7 +84,7 @@ static void vtmmio_stop(device_t);
> static void   vtmmio_poll(device_t);
> static intvtmmio_reinit(device_t, uint64_t);
> static void   vtmmio_reinit_complete(device_t);
> -static void  vtmmio_notify_virtqueue(device_t, uint16_t);
> +static void  vtmmio_notify_virtqueue(device_t, uint16_t, bus_size_t);
> static uint8_tvtmmio_get_status(device_t);
> static void   vtmmio_set_status(device_t, uint8_t);
> static void   vtmmio_read_dev_config(device_t, bus_size_t, void *, int);
> @@ -352,6 +352,13 @@ vtmmio_read_ivar(device_t dev, device_t child, int 
> index, uintptr_t *result)
>*/
>   *result = 0;
>   break;
> + case VIRTIO_IVAR_MODERN:
> + /*
> +  * There are several modern (aka MMIO v2) spec compliance
> +  * issues with this driver, but keep the status quo.
> +  */
> + *result = sc->vtmmio_version > 1;
> + break;
>   default:
>   return (ENOENT);
>   }
> @@ -388,6 +395,10 @@ vtmmio_negotiate_features(device_t dev, uint64_t 
> child_features)
> 
>   sc = device_get_softc(dev);
> 
> + if (sc->vtmmio_version > 1) {
> + child_features |= VIRTIO_F_VERSION_1;
> + }
> +
>   vtmmio_write_config_4(sc, VIRTIO_MMIO_HOST_FEATURES_SEL, 1);
>   host_features = vtmmio_read_config_4(sc, VIRTIO_MMIO_HOST_FEATURES);
>   host_features <<= 32;
> @@ -402,7 +413,7 @@ vtmmio_negotiate_features(device_t 

Re: git: 248f0cabca75 - main - make maximum interrupt number tunable on ARM, ARM64, MIPS, and RISC-V

2021-01-19 Thread Jessica Clarke
On 19 Jan 2021, at 00:36, Oleksandr Tymoshenko  wrote:
> @@ -142,21 +143,15 @@ static bool irq_assign_cpu = false;
> #endif
> #endif
> 
> -/*
> - * - 2 counters for each I/O interrupt.
> - * - MAXCPU counters for each IPI counters for SMP.
> - */
> -#ifdef SMP
> -#define INTRCNT_COUNT   (NIRQ * 2 + INTR_IPI_COUNT * MAXCPU)
> -#else
> -#define INTRCNT_COUNT   (NIRQ * 2)
> -#endif
> +int intr_nirq = NIRQ;
> +SYSCTL_UINT(_machdep, OID_AUTO, nirq, CTLFLAG_RDTUN, &intr_nirq, 0,
> +"Number of IRQs");

Unsigned integer, given the SYSCTL_UINT?

What's stopping us from dynamically resizing rather than forcing the
user to use a tunable (which also means that, in practice, the limit
will remain unchanged, because you want GENERIC kernels to work out of
the box)?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: c1a3d7f20696 - main - Remove remaining uses of ${COMPILER_FEATURES:Mc++11}

2021-01-19 Thread Jessica Clarke
On 19 Jan 2021, at 21:38, Alex Richardson  wrote:
> diff --git a/usr.sbin/Makefile b/usr.sbin/Makefile
> index bd2f0cbe0797..2e01b0fcf847 100644
> --- a/usr.sbin/Makefile
> +++ b/usr.sbin/Makefile
> @@ -186,9 +186,7 @@ SUBDIR.${MK_NTP}+=ntp
> SUBDIR.${MK_OPENSSL}+=keyserv
> SUBDIR.${MK_PF}+= ftp-proxy
> SUBDIR.${MK_PKGBOOTSTRAP}+=   pkg
> -.if ${COMPILER_FEATURES:Mc++11}
> -SUBDIR.${MK_PMC}+=   pmc
> -.endif
> +SUBDIR.${MK_PMC}.${MK_CXX}+= pmc

src.opts.mk already disables MK_PMC is MK_CXX is no.

Jess.

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 0e72f2c54186 - main - virtio_mmio: Fix a style(9) issue

2021-01-20 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=0e72f2c54186aaf2f36d96a64f36d9a94627a03f

commit 0e72f2c54186aaf2f36d96a64f36d9a94627a03f
Author: Jessica Clarke 
AuthorDate: 2021-01-21 01:02:30 +
Commit: Jessica Clarke 
CommitDate: 2021-01-21 01:05:20 +

virtio_mmio: Fix a style(9) issue
---
 sys/dev/virtio/mmio/virtio_mmio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sys/dev/virtio/mmio/virtio_mmio.c 
b/sys/dev/virtio/mmio/virtio_mmio.c
index 694d2a232fdd..c16ecd40a250 100644
--- a/sys/dev/virtio/mmio/virtio_mmio.c
+++ b/sys/dev/virtio/mmio/virtio_mmio.c
@@ -219,7 +219,7 @@ vtmmio_attach(device_t dev)
rid = 0;
sc->res[0] = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid,
RF_ACTIVE);
-   if (!sc->res[0]) {
+   if (sc->res[0] == NULL) {
device_printf(dev, "Cannot allocate memory window.\n");
return (ENXIO);
}
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: be79a2c60fec - main - virtio_mmio: Fix V1 device probing spec conformance (section 4.2.3.1.1)

2021-01-20 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=be79a2c60fec0b4ead6369e6ce420a664a0dfa9d

commit be79a2c60fec0b4ead6369e6ce420a664a0dfa9d
Author: Jessica Clarke 
AuthorDate: 2021-01-21 01:03:44 +
Commit: Jessica Clarke 
CommitDate: 2021-01-21 01:05:21 +

virtio_mmio: Fix V1 device probing spec conformance (section 4.2.3.1.1)

We must check MagicValue not just Version before anything else, and then
we must check DeviceID and immediately abort if zero (and this must not
be an error).

Do all this when probing rather than at the start of attaching as that's
where this belongs, and provides a clear boundary between the device
detection and device initialisation parts of the specified driver
initialisation process. This also means we don't create empty device
instances for placeholder devices, reducing clutter on systems that
pre-allocate a large number, such as QEMU's AArch64 virt machine (which
provides 32).

Reviewed by:bryanv
Differential Revision:  https://reviews.freebsd.org/D28070
---
 sys/dev/virtio/mmio/virtio_mmio.c  | 50 --
 sys/dev/virtio/mmio/virtio_mmio.h  |  2 ++
 sys/dev/virtio/mmio/virtio_mmio_acpi.c |  3 +-
 sys/dev/virtio/mmio/virtio_mmio_fdt.c  |  3 +-
 4 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/sys/dev/virtio/mmio/virtio_mmio.c 
b/sys/dev/virtio/mmio/virtio_mmio.c
index c16ecd40a250..862272b917df 100644
--- a/sys/dev/virtio/mmio/virtio_mmio.c
+++ b/sys/dev/virtio/mmio/virtio_mmio.c
@@ -171,6 +171,48 @@ DEFINE_CLASS_0(virtio_mmio, vtmmio_driver, vtmmio_methods,
 
 MODULE_VERSION(virtio_mmio, 1);
 
+int
+vtmmio_probe(device_t dev)
+{
+   struct vtmmio_softc *sc;
+   int rid;
+   uint32_t magic, version;
+
+   sc = device_get_softc(dev);
+
+   rid = 0;
+   sc->res[0] = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid,
+   RF_ACTIVE);
+   if (sc->res[0] == NULL) {
+   device_printf(dev, "Cannot allocate memory window.\n");
+   return (ENXIO);
+   }
+
+   magic = vtmmio_read_config_4(sc, VIRTIO_MMIO_MAGIC_VALUE);
+   if (magic != VIRTIO_MMIO_MAGIC_VIRT) {
+   device_printf(dev, "Bad magic value %#x\n", magic);
+   bus_release_resource(dev, SYS_RES_MEMORY, rid, sc->res[0]);
+   return (ENXIO);
+   }
+
+   version = vtmmio_read_config_4(sc, VIRTIO_MMIO_VERSION);
+   if (version < 1 || version > 2) {
+   device_printf(dev, "Unsupported version: %#x\n", version);
+   bus_release_resource(dev, SYS_RES_MEMORY, rid, sc->res[0]);
+   return (ENXIO);
+   }
+
+   if (vtmmio_read_config_4(sc, VIRTIO_MMIO_DEVICE_ID) == 0) {
+   bus_release_resource(dev, SYS_RES_MEMORY, rid, sc->res[0]);
+   return (ENXIO);
+   }
+
+   bus_release_resource(dev, SYS_RES_MEMORY, rid, sc->res[0]);
+
+   device_set_desc(dev, "VirtIO MMIO adapter");
+   return (BUS_PROBE_DEFAULT);
+}
+
 static int
 vtmmio_setup_intr(device_t dev, enum intr_type type)
 {
@@ -225,14 +267,6 @@ vtmmio_attach(device_t dev)
}
 
sc->vtmmio_version = vtmmio_read_config_4(sc, VIRTIO_MMIO_VERSION);
-   if (sc->vtmmio_version < 1 || sc->vtmmio_version > 2) {
-   device_printf(dev, "Unsupported version: %x\n",
-   sc->vtmmio_version);
-   bus_release_resource(dev, SYS_RES_MEMORY, 0,
-   sc->res[0]);
-   sc->res[0] = NULL;
-   return (ENXIO);
-   }
 
vtmmio_reset(sc);
 
diff --git a/sys/dev/virtio/mmio/virtio_mmio.h 
b/sys/dev/virtio/mmio/virtio_mmio.h
index ce60cd4fa173..5eb56d860780 100644
--- a/sys/dev/virtio/mmio/virtio_mmio.h
+++ b/sys/dev/virtio/mmio/virtio_mmio.h
@@ -55,6 +55,7 @@ struct vtmmio_softc {
void*ih;
 };
 
+int vtmmio_probe(device_t);
 int vtmmio_attach(device_t);
 
 #defineVIRTIO_MMIO_MAGIC_VALUE 0x000
@@ -84,6 +85,7 @@ int vtmmio_attach(device_t);
 #defineVIRTIO_MMIO_QUEUE_USED_HIGH 0x0a4   /* requires version 2 */
 #defineVIRTIO_MMIO_CONFIG_GENERATION   0x100   /* requires version 2 */
 #defineVIRTIO_MMIO_CONFIG  0x100
+#defineVIRTIO_MMIO_MAGIC_VIRT  0x74726976
 #defineVIRTIO_MMIO_INT_VRING   (1 << 0)
 #defineVIRTIO_MMIO_INT_CONFIG  (1 << 1)
 #defineVIRTIO_MMIO_VRING_ALIGN 4096
diff --git a/sys/dev/virtio/mmio/virtio_mmio_acpi.c 
b/sys/dev/virtio/mmio/virtio_mmio_acpi.c
index bd737a6e53db..0cb34f5aa873 100644
--- a/sys/dev/virtio/mmio/virtio_mmio_acpi.c
+++ b/sys/dev/virtio/mmio/virtio_mmio_acpi.c
@@ -81,6 +81,5 @@ vtmmio_acpi_probe(device_t dev)
if (!ac

git: 633218ee4615 - main - virtio: Reduce boilerplate for device driver module definitions

2021-01-20 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=633218ee4615854702fea05ba6e17c2a1876bb6b

commit 633218ee4615854702fea05ba6e17c2a1876bb6b
Author: Jessica Clarke 
AuthorDate: 2021-01-21 01:07:23 +
Commit: Jessica Clarke 
CommitDate: 2021-01-21 01:07:23 +

virtio: Reduce boilerplate for device driver module definitions

Rather than have every device register itself for both virtio_pci and
virtio_mmio, provide a VIRTIO_DRIVER_MODULE wrapper to declare both,
merge VIRTIO_SIMPLE_PNPTABLE with VIRTIO_SIMPLE_PNPINFO and make the
latter register for both buses. This also has the benefit of abstracting
away the available transports and their names.

Reviewed by:bryanv
Differential Revision:  https://reviews.freebsd.org/D28073
---
 sys/dev/virtio/balloon/virtio_balloon.c |  8 ++--
 sys/dev/virtio/block/virtio_blk.c   |  8 ++--
 sys/dev/virtio/console/virtio_console.c |  8 ++--
 sys/dev/virtio/network/if_vtnet.c   |  8 ++--
 sys/dev/virtio/random/virtio_random.c   |  8 ++--
 sys/dev/virtio/scsi/virtio_scsi.c   |  8 ++--
 sys/dev/virtio/virtio.h | 13 +
 7 files changed, 21 insertions(+), 40 deletions(-)

diff --git a/sys/dev/virtio/balloon/virtio_balloon.c 
b/sys/dev/virtio/balloon/virtio_balloon.c
index 848dd4e9a7f5..3e2d967dd9af 100644
--- a/sys/dev/virtio/balloon/virtio_balloon.c
+++ b/sys/dev/virtio/balloon/virtio_balloon.c
@@ -158,17 +158,13 @@ static driver_t vtballoon_driver = {
 };
 static devclass_t vtballoon_devclass;
 
-DRIVER_MODULE(virtio_balloon, virtio_mmio, vtballoon_driver,
-vtballoon_devclass, 0, 0);
-DRIVER_MODULE(virtio_balloon, virtio_pci, vtballoon_driver,
+VIRTIO_DRIVER_MODULE(virtio_balloon, vtballoon_driver,
 vtballoon_devclass, 0, 0);
 MODULE_VERSION(virtio_balloon, 1);
 MODULE_DEPEND(virtio_balloon, virtio, 1, 1, 1);
 
-VIRTIO_SIMPLE_PNPTABLE(virtio_balloon, VIRTIO_ID_BALLOON,
+VIRTIO_SIMPLE_PNPINFO(virtio_balloon, VIRTIO_ID_BALLOON,
 "VirtIO Balloon Adapter");
-VIRTIO_SIMPLE_PNPINFO(virtio_mmio, virtio_balloon);
-VIRTIO_SIMPLE_PNPINFO(virtio_pci, virtio_balloon);
 
 static int
 vtballoon_probe(device_t dev)
diff --git a/sys/dev/virtio/block/virtio_blk.c 
b/sys/dev/virtio/block/virtio_blk.c
index 6056771e3735..50642fb0b009 100644
--- a/sys/dev/virtio/block/virtio_blk.c
+++ b/sys/dev/virtio/block/virtio_blk.c
@@ -267,16 +267,12 @@ static driver_t vtblk_driver = {
 };
 static devclass_t vtblk_devclass;
 
-DRIVER_MODULE(virtio_blk, virtio_mmio, vtblk_driver, vtblk_devclass,
-vtblk_modevent, 0);
-DRIVER_MODULE(virtio_blk, virtio_pci, vtblk_driver, vtblk_devclass,
+VIRTIO_DRIVER_MODULE(virtio_blk, vtblk_driver, vtblk_devclass,
 vtblk_modevent, 0);
 MODULE_VERSION(virtio_blk, 1);
 MODULE_DEPEND(virtio_blk, virtio, 1, 1, 1);
 
-VIRTIO_SIMPLE_PNPTABLE(virtio_blk, VIRTIO_ID_BLOCK, "VirtIO Block Adapter");
-VIRTIO_SIMPLE_PNPINFO(virtio_mmio, virtio_blk);
-VIRTIO_SIMPLE_PNPINFO(virtio_pci, virtio_blk);
+VIRTIO_SIMPLE_PNPINFO(virtio_blk, VIRTIO_ID_BLOCK, "VirtIO Block Adapter");
 
 static int
 vtblk_modevent(module_t mod, int type, void *unused)
diff --git a/sys/dev/virtio/console/virtio_console.c 
b/sys/dev/virtio/console/virtio_console.c
index 315eb59716b4..b65935303b21 100644
--- a/sys/dev/virtio/console/virtio_console.c
+++ b/sys/dev/virtio/console/virtio_console.c
@@ -263,17 +263,13 @@ static driver_t vtcon_driver = {
 };
 static devclass_t vtcon_devclass;
 
-DRIVER_MODULE(virtio_console, virtio_mmio, vtcon_driver, vtcon_devclass,
-vtcon_modevent, 0);
-DRIVER_MODULE(virtio_console, virtio_pci, vtcon_driver, vtcon_devclass,
+VIRTIO_DRIVER_MODULE(virtio_console, vtcon_driver, vtcon_devclass,
 vtcon_modevent, 0);
 MODULE_VERSION(virtio_console, 1);
 MODULE_DEPEND(virtio_console, virtio, 1, 1, 1);
 
-VIRTIO_SIMPLE_PNPTABLE(virtio_console, VIRTIO_ID_CONSOLE,
+VIRTIO_SIMPLE_PNPINFO(virtio_console, VIRTIO_ID_CONSOLE,
 "VirtIO Console Adapter");
-VIRTIO_SIMPLE_PNPINFO(virtio_mmio, virtio_console);
-VIRTIO_SIMPLE_PNPINFO(virtio_pci, virtio_console);
 
 static int
 vtcon_modevent(module_t mod, int type, void *unused)
diff --git a/sys/dev/virtio/network/if_vtnet.c 
b/sys/dev/virtio/network/if_vtnet.c
index 8d0770f5ac2d..e64b7de113c8 100644
--- a/sys/dev/virtio/network/if_vtnet.c
+++ b/sys/dev/virtio/network/if_vtnet.c
@@ -362,9 +362,7 @@ static driver_t vtnet_driver = {
 };
 static devclass_t vtnet_devclass;
 
-DRIVER_MODULE(vtnet, virtio_mmio, vtnet_driver, vtnet_devclass,
-vtnet_modevent, 0);
-DRIVER_MODULE(vtnet, virtio_pci, vtnet_driver, vtnet_devclass,
+VIRTIO_DRIVER_MODULE(vtnet, vtnet_driver, vtnet_devclass,
 vtnet_modevent, 0);
 MODULE_VERSION(vtnet, 1);
 MODULE_DEPEND(vtnet, virtio, 1, 1, 1);
@@ -372,9 +370,7 @@ MODULE_DEPEND(vtnet, virtio, 1, 1, 1);
 MODULE_DEPEND(vtnet, netmap, 1, 1, 1);
 #endif
 
-VIRTIO_SIMPLE_PNPTABLE(vtnet, VIRTI

git: 32cb85d0f1e8 - main - Build VirtIO modules on all architectures

2021-01-20 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=32cb85d0f1e806ac2147fefff6b6e3bd107ba4c1

commit 32cb85d0f1e806ac2147fefff6b6e3bd107ba4c1
Author: Jessica Clarke 
AuthorDate: 2021-01-21 01:21:35 +
Commit: Jessica Clarke 
CommitDate: 2021-01-21 01:21:35 +

Build VirtIO modules on all architectures

Currently only amd64, i386 and powerpc build VirtIO modules, yet all other
architectures have at least one kernel configuration that includes the
transport drivers, and so they lack drivers for all the devices they don't
statically compile into the kernel. Instead, enable the build everywhere so 
all
architectures have the full set of device drivers available.

Reviewed by:bryanv (earlier version), imp (earlier version)
Differential Revision:  https://reviews.freebsd.org/D28058
---
 share/man/man4/Makefile | 32 
 sys/modules/Makefile|  4 +---
 2 files changed, 9 insertions(+), 27 deletions(-)

diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile
index fa2af9d32aea..ffc7a08292e9 100644
--- a/share/man/man4/Makefile
+++ b/share/man/man4/Makefile
@@ -564,12 +564,12 @@ MAN=  aac.4 \
vge.4 \
viapm.4 \
${_viawd.4} \
-   ${_virtio.4} \
-   ${_virtio_balloon.4} \
-   ${_virtio_blk.4} \
-   ${_virtio_console.4} \
-   ${_virtio_random.4} \
-   ${_virtio_scsi.4} \
+   virtio.4 \
+   virtio_balloon.4 \
+   virtio_blk.4 \
+   virtio_console.4 \
+   virtio_random.4 \
+   virtio_scsi.4 \
${_vmci.4} \
vkbd.4 \
vlan.4 \
@@ -580,7 +580,7 @@ MAN=aac.4 \
vr.4 \
vt.4 \
vte.4 \
-   ${_vtnet.4} \
+   vtnet.4 \
watchdog.4 \
${_wbwd.4} \
witness.4 \
@@ -764,7 +764,7 @@ MLINKS+=vxlan.4 if_vxlan.4
 MLINKS+=${_vmx.4} ${_if_vmx.4}
 MLINKS+=vr.4 if_vr.4
 MLINKS+=vte.4 if_vte.4
-MLINKS+=${_vtnet.4} ${_if_vtnet.4}
+MLINKS+=vtnet.4 if_vtnet.4
 MLINKS+=watchdog.4 SW_WATCHDOG.4
 MLINKS+=${_wpi.4} ${_if_wpi.4}
 MLINKS+=xl.4 if_xl.4
@@ -818,7 +818,6 @@ _if_ndis.4= if_ndis.4
 _if_nfe.4= if_nfe.4
 _if_urtw.4=if_urtw.4
 _if_vmx.4= if_vmx.4
-_if_vtnet.4=   if_vtnet.4
 _if_wpi.4= if_wpi.4
 _imcsmb.4= imcsmb.4
 _ipmi.4=   ipmi.4
@@ -849,15 +848,8 @@ _superio.4=superio.4
 _tpm.4=tpm.4
 _urtw.4=   urtw.4
 _viawd.4=  viawd.4
-_virtio.4= virtio.4
-_virtio_balloon.4=virtio_balloon.4
-_virtio_blk.4= virtio_blk.4
-_virtio_console.4=virtio_console.4
-_virtio_random.4= virtio_random.4
-_virtio_scsi.4= virtio_scsi.4
 _vmci.4=   vmci.4
 _vmx.4=vmx.4
-_vtnet.4=  vtnet.4
 _wbwd.4=   wbwd.4
 _wpi.4=wpi.4
 _xen.4=xen.4
@@ -895,16 +887,8 @@ _nvram2env.4=  nvram2env.4
 .endif
 
 .if ${MACHINE_CPUARCH} == "powerpc"
-_if_vtnet.4=if_vtnet.4
 _nvd.4=nvd.4
 _nvme.4=   nvme.4
-_virtio.4= virtio.4
-_virtio_balloon.4=virtio_balloon.4
-_virtio_blk.4= virtio_blk.4
-_virtio_console.4=virtio_console.4
-_virtio_random.4= virtio_random.4
-_virtio_scsi.4=virtio_scsi.4
-_vtnet.4=  vtnet.4
 .endif
 
 .if ${MACHINE_CPUARCH} == "arm" || ${MACHINE_CPUARCH} == "aarch64" || \
diff --git a/sys/modules/Makefile b/sys/modules/Makefile
index 320f4002f817..f5dd13527f08 100644
--- a/sys/modules/Makefile
+++ b/sys/modules/Makefile
@@ -376,7 +376,7 @@ SUBDIR= \
unionfs \
usb \
${_vesa} \
-   ${_virtio} \
+   virtio \
vge \
${_viawd} \
videomode \
@@ -722,7 +722,6 @@ _tpm=   tpm
 _twa=  twa
 _vesa= vesa
 _viawd=viawd
-_virtio=   virtio
 _wpi=  wpi
 .if ${MK_SOURCELESS_UCODE} != "no"
 _wpifw=wpifw
@@ -794,7 +793,6 @@ _ffec=  ffec
 _nvd=  nvd
 _nvme= nvme
 _pccard=   pccard
-_virtio=   virtio
 .endif
 
 .if ${MACHINE_ARCH:Mpowerpc64*} != ""
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 5faeda903753 - main - Rename i386's Linux ELF to Linux ELF32

2021-01-20 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=5faeda903753d20a7a857167a68713d1659474e1

commit 5faeda903753d20a7a857167a68713d1659474e1
Author: Jessica Clarke 
AuthorDate: 2021-01-21 01:54:12 +
Commit: Jessica Clarke 
CommitDate: 2021-01-21 01:54:12 +

Rename i386's Linux ELF to Linux ELF32

This is what amd64 calls the i386 Linux ABI in order to distinguish it
from the amd64 Linux ABI, and matches the nomenclature used for the
FreeBSD ABIs where they always have the size suffix in the name.

Reviewed by:trasz
Differential Revision:  https://reviews.freebsd.org/D27647
---
 sys/i386/linux/linux_sysvec.c | 2 +-
 usr.bin/truss/setup.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_sysvec.c
index 7bd1102e48a0..10229d8af57e 100644
--- a/sys/i386/linux/linux_sysvec.c
+++ b/sys/i386/linux/linux_sysvec.c
@@ -882,7 +882,7 @@ struct sysentvec elf_linux_sysvec = {
.sv_sendsig = linux_sendsig,
.sv_sigcode = &_binary_linux_locore_o_start,
.sv_szsigcode   = &linux_szsigcode,
-   .sv_name= "Linux ELF",
+   .sv_name= "Linux ELF32",
.sv_coredump= elf32_coredump,
.sv_imgact_try  = linux_exec_imgact_try,
.sv_minsigstksz = LINUX_MINSIGSTKSZ,
diff --git a/usr.bin/truss/setup.c b/usr.bin/truss/setup.c
index 172d7d5d366c..d21ec133f483 100644
--- a/usr.bin/truss/setup.c
+++ b/usr.bin/truss/setup.c
@@ -141,7 +141,7 @@ static struct procabi_table abis[] = {
{ "Linux ELF64", &linux },
{ "Linux ELF32", &linux32 },
 #else
-   { "Linux ELF", &linux },
+   { "Linux ELF32", &linux },
 #endif
 };
 
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 513c5cd8276c - main - linux64: Don't pass unnecessary -S and -g to objcopy

2021-01-20 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=513c5cd8276c262e4f81e5d3a717f3725a835d56

commit 513c5cd8276c262e4f81e5d3a717f3725a835d56
Author: Jessica Clarke 
AuthorDate: 2021-01-21 01:54:52 +
Commit: Jessica Clarke 
CommitDate: 2021-01-21 01:54:52 +

linux64: Don't pass unnecessary -S and -g to objcopy

Since we use --input-type binary these options are rather meaningless. Both
binutils and elftoolchain ignore the option in this case, but LLVM does not,
and instead strips all symbols from the output file, causing missing 
symbols at
run time if building with llvm-objcopy. Thus simply remove the options; the
linux module has never included them for building its VDSO (added in 
r283407),
but for some reason the original commit of linux64 (r283424) added them.

These should however eventually be changed to use template assembly files 
as is
now done for firmware and MFS_IMAGE.

Reviewed by:emaste, trasz
Differential Revision:  https://reviews.freebsd.org/D27740
---
 sys/modules/linux64/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sys/modules/linux64/Makefile b/sys/modules/linux64/Makefile
index 91b419558d82..ebc69168bd4a 100644
--- a/sys/modules/linux64/Makefile
+++ b/sys/modules/linux64/Makefile
@@ -50,7 +50,7 @@ OBJCOPY_TARGET=--output-target elf64-x86-64 
--binary-architecture i386:x86-64
 .error ${MACHINE_CPUARCH} not yet supported by linux64
 .endif
 ${VDSO}.so: linux_locore.o
-   ${OBJCOPY} --input-target binary ${OBJCOPY_TARGET} -S -g \
+   ${OBJCOPY} --input-target binary ${OBJCOPY_TARGET} \
linux_locore.o ${.TARGET}
${STRIPBIN} -N _binary_linux_locore_o_size ${.TARGET}
 
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 85ad7f8da19f - main - virtio_mmio: Delete a stale #if 0'ed debug print

2021-01-20 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=85ad7f8da19fbd5985690d4ccfcc45952713dd1b

commit 85ad7f8da19fbd5985690d4ccfcc45952713dd1b
Author: Jessica Clarke 
AuthorDate: 2021-01-21 02:14:41 +
Commit: Jessica Clarke 
CommitDate: 2021-01-21 02:14:41 +

virtio_mmio: Delete a stale #if 0'ed debug print

This was blindly moved in r360722 but the variable being printed is not
yet initialised. It's of little use and can easily be added back in the
right place if needed by someone debugging, so just delete it.

Reported by:bryanv
---
 sys/dev/virtio/mmio/virtio_mmio.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/sys/dev/virtio/mmio/virtio_mmio.c 
b/sys/dev/virtio/mmio/virtio_mmio.c
index 862272b917df..5672a6f0f69c 100644
--- a/sys/dev/virtio/mmio/virtio_mmio.c
+++ b/sys/dev/virtio/mmio/virtio_mmio.c
@@ -478,10 +478,7 @@ vtmmio_set_virtqueue(struct vtmmio_softc *sc, struct 
virtqueue *vq,
vm_paddr_t paddr;
 
vtmmio_write_config_4(sc, VIRTIO_MMIO_QUEUE_NUM, size);
-#if 0
-   device_printf(dev, "virtqueue paddr 0x%08lx\n",
-   (uint64_t)paddr);
-#endif
+
if (sc->vtmmio_version == 1) {
vtmmio_write_config_4(sc, VIRTIO_MMIO_QUEUE_ALIGN,
VIRTIO_MMIO_VRING_ALIGN);
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: a9fc14fbf445 - main - newvers.sh: add support for gitup(1)

2021-01-21 Thread Jessica Clarke
On 21 Jan 2021, at 14:32, Mateusz Guzik  wrote:
> On 1/21/21, Ed Maste  wrote:
>> On Thu, 21 Jan 2021 at 05:37, Mateusz Guzik  wrote:
>>> 
>>> I'm getting an error with this:
>>> 
>>> $ make -s buildkernel MODULES_OVERRIDE=""
>>> 
>>> /tank/users/mjg/src/freebsd/sys/conf/newvers.sh: git: not found
>>> 
 + if [ "$(git rev-parse --is-shallow-repository)" = false ] ; then
>>  ^^^
>> Looks like this bare git should be $git_cmd, can you confirm that
>> change fixes it?
> 
> This fixes the problem at hand, but a new regression is shown:
> 
> $ strings kernel | grep 'FreeBSD 13.0-ALPHA1'
> FreeBSD 13.0-ALPHA1 #47 c256181-gb06e91d1b700: Thu Jan 21 14:31:35 UTC 2021
> 
> branch name is no longer present.

See the commit message, though I'd argue it's not redundant in a lot of
local development cases (i.e. anything other than main, stable/*, etc),
and is actually rather useful.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: d6327ae8c11b - main - Fix cross-build support for Ubuntu 16.04

2021-01-23 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=d6327ae8c11b73765f100981baca49166b558b70

commit d6327ae8c11b73765f100981baca49166b558b70
Author: Jessica Clarke 
AuthorDate: 2021-01-23 20:59:15 +
Commit: Jessica Clarke 
CommitDate: 2021-01-23 20:59:15 +

Fix cross-build support for Ubuntu 16.04

Older glibc headers did some very nasty things that have since been
sanitised. We could also fix this by adding a linux/getopt.h wrapper
alongside the existing common/getopt.h that #undef's __need_getopt, but
that seems a little more hacky and complicated.

Reviewed by:arichardson
---
 tools/build/cross-build/include/linux/unistd.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/build/cross-build/include/linux/unistd.h 
b/tools/build/cross-build/include/linux/unistd.h
index 9d1bd1bf4025..ea131f1ab732 100644
--- a/tools/build/cross-build/include/linux/unistd.h
+++ b/tools/build/cross-build/include/linux/unistd.h
@@ -41,9 +41,17 @@
 /* Ensure that unistd.h pulls in getopt */
 #define __USE_POSIX2
 #endif
+/*
+ * Before version 2.25, glibc's unistd.h would define the POSIX subset of
+ * getopt.h by defining __need_getopt,  including getopt.h (which would
+ * disable the header guard) and then undefining it so later including
+ * getopt.h explicitly would define the extensions. However, we wrap getopt,
+ * and so the wrapper's #pragma once breaks that. Thus getopt.h must be
+ * included before the real unistd.h to ensure we get all the extensions.
+ */
+#include 
 #include_next 
 #include 
-#include 
 #include 
 #include 
 #include 
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 83edbc3cb54f - main - ipfilter: Retire pre-standard C support.

2021-01-25 Thread Jessica Clarke
Hi,

On 25 Jan 2021, at 22:47, Cy Schubert  wrote:
> 
> diff --git a/contrib/ipfilter/ipf.h b/contrib/ipfilter/ipf.h
> index 05dcfa4afd64..834ba83f51f0 100644
> --- a/contrib/ipfilter/ipf.h
> +++ b/contrib/ipfilter/ipf.h
> @@ -73,15 +73,7 @@
> #include "opts.h"
> 
> #ifndef __P
> -# ifdef __STDC__
> #  define __P(x)  x

There are a few cases like this where the indentation should be reduced
(or just removed if it's no longer so confusing).

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: cc96f92a570e - main - atomic: make atomic_store_ptr type-aware

2021-01-25 Thread Jessica Clarke
On 25 Jan 2021, at 22:42, Mateusz Guzik  wrote:
> index a3548977b940..4c29d132c369 100644
> --- a/sys/sys/atomic_common.h
> +++ b/sys/sys/atomic_common.h
> @@ -58,7 +58,7 @@
> #define   atomic_store_long(p, v) \
> (*(volatile u_long *)(p) = (u_long)(v))
> #define   atomic_store_ptr(p, v)  \
> -(*(volatile uintptr_t *)(p) = (uintptr_t)(v))
> +(*(volatile __typeof(*p) *)(p) = (v))

This is in fact general enough to be any of the atomic_store_*, and
won't give any errors if you use it for a uint16_t (where it will store
a uint16_t).

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 054ce2b03710 - main - atomic: add stub atomic_load_consume_ptr

2021-01-25 Thread Jessica Clarke
On 25 Jan 2021, at 22:42, Mateusz Guzik  wrote:
> 
> The branch main has been updated by mjg:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=054ce2b0371042c0dbc4b3ab1d7e7795ad75d51e
> 
> commit 054ce2b0371042c0dbc4b3ab1d7e7795ad75d51e
> Author: Mateusz Guzik 
> AuthorDate: 2021-01-25 20:09:41 +
> Commit: Mateusz Guzik 
> CommitDate: 2021-01-25 22:40:15 +
> 
>atomic: add stub atomic_load_consume_ptr

Consume semantics is a waste of time, it's basically impossible to
implement in an optimising compiler as, in order to not emit the same
fences as an acquire, you need the source dependencies to be mapped to
data dependencies in the output assembly, but all manner of
transformations can cause that to break. And that's before you get to
hand-written atomic implementations where it is impossible for you to
ensure that, as you're not even telling the compiler what you're doing.
For example:

  int x = atomic_load_consume_int(p);
  int y = q[x - x];

This looks like stupid code, but the `x - x` cannot be constant-folded
without inserting a barrier, as currently there is data dependence at
the source level. If you use language-level atomics then it "works" by
virtue of compilers just turning consumes into acquires so the later
constant folding is safe. But if your atomic_load_consume_int is
hand-rolled magic assembly then the compiler has no clue and will
blindly go and constant fold that subtraction for you, completely
breaking your synchronisation.

Providing consume loads just doesn't make sense for FreeBSD's atomics
except for documenting the exact requirements of the code being written;
they can never be implemented as anything other than acquire loads
unless we migrate to using actual C11 atomics, but even then you won't
get any code generation difference and likely never will.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 48397f6c7d2d - main - libllvmminimal: Add missing Support/ABIBreak.cpp

2021-01-27 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=48397f6c7d2d693602105d8ec24c5741202e264d

commit 48397f6c7d2d693602105d8ec24c5741202e264d
Author: Jessica Clarke 
AuthorDate: 2021-01-27 19:19:00 +
Commit: Jessica Clarke 
CommitDate: 2021-01-27 19:19:00 +

libllvmminimal: Add missing Support/ABIBreak.cpp

When building natively on RISC-V, linking the bootstrap clang-tblgen
fails with:

  ld: error: undefined symbol: llvm::EnableABIBreakingChecks
  >>> referenced by PrettyStackTrace.cpp
  >>>   PrettyStackTrace.o:(.sdata+0x0) in archive
  
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
  >>> referenced by Signals.cpp
  >>>   Signals.o:(.sdata+0x8) in archive
  
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
  >>> referenced by Timer.cpp
  >>>   Timer.o:(.sdata+0x28) in archive
  
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a

This is likely due to Error.h's inclusion of abi-breaking.h. It's
unclear why this only affects RISC-V, but perhaps relates to its more
eager use of .sdata due to the ABI's support for linker relaxations.
Regardless, this is theoretically an issue for all architectures.

Reported by:Dennis Clarke 
Reviewed by:dim
Tested by:  mhorne
MFC after:  3 days
Differential Revision:  https://reviews.freebsd.org/D28367
---
 lib/clang/libllvmminimal/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/clang/libllvmminimal/Makefile 
b/lib/clang/libllvmminimal/Makefile
index 0b5a204583fb..76826547ddbf 100644
--- a/lib/clang/libllvmminimal/Makefile
+++ b/lib/clang/libllvmminimal/Makefile
@@ -7,6 +7,7 @@ INTERNALLIB=
 
 SRCDIR=llvm/lib
 SRCS+= Demangle/ItaniumDemangle.cpp
+SRCS+= Support/ABIBreak.cpp
 SRCS+= Support/APFloat.cpp
 SRCS+= Support/APInt.cpp
 SRCS+= Support/ARMTargetParser.cpp
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 5fe433a6e4d8 - main - netgraph/ng_nat: Add RFC 6598/Carrier Grade NAT support

2021-01-27 Thread Jessica Clarke
On 27 Jan 2021, at 19:55, John Baldwin  wrote:
> On 1/24/21 11:51 AM, Kyle Evans wrote:
>> On Sun, Jan 24, 2021 at 1:47 PM Lutz Donnerhacke  wrote:
>> We switched up the recommendations[0][1] to advocate for what you've
>> done here ~2 weeks ago -- so yes, this is good. :-)
> 
> Note that "Submitted by" may still be needed when there are multiple
> authors who contribute to a patch.  (And I do kind of think pulling
> it from the template was a bit hasty as it didn't take those cases
> into account.)  I do think we want Author to reflect the primary
> author of the change though.

The git world (or at least the GitHub world) seems to be settling in
Co-authored-by: for that, which is more accurate.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 83ff5d5d98cb - main - Un-XFAIL two tests with Clang > 10

2021-01-28 Thread Jessica Clarke
Is the commit message or the diff wrong? Both use strict inequalities.

Jess

On 28 Jan 2021, at 17:39, Alex Richardson  wrote:
> 
> The branch main has been updated by arichardson:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=83ff5d5d98cbcf9b66dccd70022358aec8918a14
> 
> commit 83ff5d5d98cbcf9b66dccd70022358aec8918a14
> Author: Alex Richardson 
> AuthorDate: 2021-01-28 17:17:49 +
> Commit: Alex Richardson 
> CommitDate: 2021-01-28 17:24:24 +
> 
>Un-XFAIL two tests with Clang > 10
> 
>SVN r343917 fixed this for in-tree clang, but when building with a newer
>out-of-tree clang the test was still marked as XFAIL.
> 
>Reviewed By:dim
>Differential Revision: https://reviews.freebsd.org/D28390
> ---
> contrib/netbsd-tests/lib/libm/t_cbrt.c | 4 ++--
> lib/msun/tests/trig_test.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/contrib/netbsd-tests/lib/libm/t_cbrt.c 
> b/contrib/netbsd-tests/lib/libm/t_cbrt.c
> index d2cdd47a5beb..08e9faeb145c 100644
> --- a/contrib/netbsd-tests/lib/libm/t_cbrt.c
> +++ b/contrib/netbsd-tests/lib/libm/t_cbrt.c
> @@ -269,8 +269,8 @@ ATF_TC_BODY(cbrtl_powl, tc)
>   size_t i;
> 
> #if defined(__amd64__) && defined(__clang__) && __clang_major__ >= 7 && \
> -__FreeBSD_cc_version < 132
> - atf_tc_expect_fail("test fails with clang 7+ - bug 234040");
> +__clang_major__ < 10 && __FreeBSD_cc_version < 132
> + atf_tc_expect_fail("test fails with clang 7-9 - bug 234040");
> #endif
> 
>   for (i = 0; i < __arraycount(x); i++) {
> diff --git a/lib/msun/tests/trig_test.c b/lib/msun/tests/trig_test.c
> index 483a5e187d50..ba1975721d3f 100644
> --- a/lib/msun/tests/trig_test.c
> +++ b/lib/msun/tests/trig_test.c
> @@ -161,7 +161,7 @@ ATF_TC_BODY(reduction, tc)
>   unsigned i;
> 
> #if defined(__amd64__) && defined(__clang__) && __clang_major__ >= 7 && \
> -__FreeBSD_cc_version < 132
> +__clang_major__ < 10 && __FreeBSD_cc_version < 132
>   atf_tc_expect_fail("test fails with clang 7+ - bug 234040");
> #endif
> 

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 83ff5d5d98cb - main - Un-XFAIL two tests with Clang > 10

2021-01-28 Thread Jessica Clarke
On 28 Jan 2021, at 17:46, Alexander Richardson  wrote:
> On Thu, 28 Jan 2021 at 17:42, Jessica Clarke  wrote:
>> 
>> Is the commit message or the diff wrong? Both use strict inequalities.
>> 
>> Jess
> 
> Sorry the commit message should be >= 10.

Thanks. I see now the first XFAIL message was updated to say 7-9 (which
answers my question), but the second one I was looking at was not.
Could you please correct that?

Jess

>> 
>> On 28 Jan 2021, at 17:39, Alex Richardson  wrote:
>>> 
>>> The branch main has been updated by arichardson:
>>> 
>>> URL: 
>>> https://cgit.FreeBSD.org/src/commit/?id=83ff5d5d98cbcf9b66dccd70022358aec8918a14
>>> 
>>> commit 83ff5d5d98cbcf9b66dccd70022358aec8918a14
>>> Author: Alex Richardson 
>>> AuthorDate: 2021-01-28 17:17:49 +
>>> Commit: Alex Richardson 
>>> CommitDate: 2021-01-28 17:24:24 +
>>> 
>>>   Un-XFAIL two tests with Clang > 10
>>> 
>>>   SVN r343917 fixed this for in-tree clang, but when building with a newer
>>>   out-of-tree clang the test was still marked as XFAIL.
>>> 
>>>   Reviewed By:dim
>>>   Differential Revision: https://reviews.freebsd.org/D28390
>>> ---
>>> contrib/netbsd-tests/lib/libm/t_cbrt.c | 4 ++--
>>> lib/msun/tests/trig_test.c | 2 +-
>>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/contrib/netbsd-tests/lib/libm/t_cbrt.c 
>>> b/contrib/netbsd-tests/lib/libm/t_cbrt.c
>>> index d2cdd47a5beb..08e9faeb145c 100644
>>> --- a/contrib/netbsd-tests/lib/libm/t_cbrt.c
>>> +++ b/contrib/netbsd-tests/lib/libm/t_cbrt.c
>>> @@ -269,8 +269,8 @@ ATF_TC_BODY(cbrtl_powl, tc)
>>>  size_t i;
>>> 
>>> #if defined(__amd64__) && defined(__clang__) && __clang_major__ >= 7 && \
>>> -__FreeBSD_cc_version < 132
>>> - atf_tc_expect_fail("test fails with clang 7+ - bug 234040");
>>> +__clang_major__ < 10 && __FreeBSD_cc_version < 132
>>> + atf_tc_expect_fail("test fails with clang 7-9 - bug 234040");
>>> #endif
>>> 
>>>  for (i = 0; i < __arraycount(x); i++) {
>>> diff --git a/lib/msun/tests/trig_test.c b/lib/msun/tests/trig_test.c
>>> index 483a5e187d50..ba1975721d3f 100644
>>> --- a/lib/msun/tests/trig_test.c
>>> +++ b/lib/msun/tests/trig_test.c
>>> @@ -161,7 +161,7 @@ ATF_TC_BODY(reduction, tc)
>>>  unsigned i;
>>> 
>>> #if defined(__amd64__) && defined(__clang__) && __clang_major__ >= 7 && \
>>> -__FreeBSD_cc_version < 132
>>> +__clang_major__ < 10 && __FreeBSD_cc_version < 132
>>>  atf_tc_expect_fail("test fails with clang 7+ - bug 234040");
>>> #endif
>>> 
>> 

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 710e45c4b853 - main - Reimplement strlen

2021-01-29 Thread Jessica Clarke
On 29 Jan 2021, at 23:48, Mateusz Guzik  wrote:
> 
> The branch main has been updated by mjg:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=710e45c4b8539d028877769f1a4ec088c48fb5f1
> 
> commit 710e45c4b8539d028877769f1a4ec088c48fb5f1
> Author: Mateusz Guzik 
> AuthorDate: 2021-01-29 21:48:11 +
> Commit: Mateusz Guzik 
> CommitDate: 2021-01-29 23:48:26 +
> 
>Reimplement strlen

This really should have gone through code review.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: bb8fa72dae42 - stable/13 - libllvmminimal: Add missing Support/ABIBreak.cpp

2021-01-30 Thread Jessica Clarke
The branch stable/13 has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=bb8fa72dae42c213d3f822865c0121577243ca18

commit bb8fa72dae42c213d3f822865c0121577243ca18
Author: Jessica Clarke 
AuthorDate: 2021-01-27 19:19:00 +
Commit: Jessica Clarke 
CommitDate: 2021-01-30 14:23:47 +

libllvmminimal: Add missing Support/ABIBreak.cpp

When building natively on RISC-V, linking the bootstrap clang-tblgen
fails with:

  ld: error: undefined symbol: llvm::EnableABIBreakingChecks
  >>> referenced by PrettyStackTrace.cpp
  >>>   PrettyStackTrace.o:(.sdata+0x0) in archive
  
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
  >>> referenced by Signals.cpp
  >>>   Signals.o:(.sdata+0x8) in archive
  
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
  >>> referenced by Timer.cpp
  >>>   Timer.o:(.sdata+0x28) in archive
  
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a

This is likely due to Error.h's inclusion of abi-breaking.h. It's
unclear why this only affects RISC-V, but perhaps relates to its more
eager use of .sdata due to the ABI's support for linker relaxations.
Regardless, this is theoretically an issue for all architectures.

Reported by:Dennis Clarke 

(cherry picked from commit 48397f6c7d2d693602105d8ec24c5741202e264d)
---
 lib/clang/libllvmminimal/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/clang/libllvmminimal/Makefile 
b/lib/clang/libllvmminimal/Makefile
index 0b5a204583fb..76826547ddbf 100644
--- a/lib/clang/libllvmminimal/Makefile
+++ b/lib/clang/libllvmminimal/Makefile
@@ -7,6 +7,7 @@ INTERNALLIB=
 
 SRCDIR=llvm/lib
 SRCS+= Demangle/ItaniumDemangle.cpp
+SRCS+= Support/ABIBreak.cpp
 SRCS+= Support/APFloat.cpp
 SRCS+= Support/APInt.cpp
 SRCS+= Support/ARMTargetParser.cpp
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: fc301c224b27 - stable/13 - atomic: add stub atomic_load_consume_ptr

2021-02-01 Thread Jessica Clarke
On 1 Feb 2021, at 13:53, Hans Petter Selasky  wrote:
> On 2/1/21 1:40 PM, Mateusz Guzik wrote:
>> +/*
>> + * Currently all architectures provide acquire and release fences on their 
>> own,
>> + * but they don't provide consume. Kludge below allows relevant code to stop
>> + * openly resorting to the stronger acquire fence, to be sorted out.
>> + */
>> +#define atomic_load_consume_ptr(p)  \
>> +((__typeof(*p)) atomic_load_acq_ptr((uintptr_t *)p))
>> +
> 
> Are you missing:
> 
> CTASSERT(sizeof(*p) == sizeof(void *)) 

I also commented on the head commit that this is a waste of time and
will likely never be anything other than an acquire, but never got a
reply.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 0c839497c174 - stable/13 - loader.efi: There are systems without ConOut, also use ConOutDev

2021-02-05 Thread Jessica Clarke
> On 5 Feb 2021, at 20:21, Warner Losh  wrote:
> 
> 
> 
> On Fri, Feb 5, 2021 at 1:09 PM Toomas Soome  > wrote:
> 
> 
>> On 5. Feb 2021, at 21:43, Warner Losh > > wrote:
>> 
>> 
>> 
>> On Fri, Feb 5, 2021 at 10:24 AM Toomas Soome > > wrote:
>> 
>> 
>>> On 5. Feb 2021, at 18:44, Warner Losh >> > wrote:
>>> 
>>> 
>>> 
>>> On Thu, Feb 4, 2021 at 11:38 PM Toomas Soome >> > wrote:
>>> 
>>> 
 On 5. Feb 2021, at 01:56, Warner Losh >>> > wrote:
 
 
 And why the instaMFC? Changes are supposed to cook force days before 
 merging... I have questions about the wisdom of this change...
 
 Warner 
 
>>> 
>>> Reason is in PR. There is someone with the system without ConOut but 
>>> ConOutDev is set. Instead of falling back to arbitrary device (which in 
>>> this case was totally wrong choice), we can try the possible devices list. 
>>> We do not change the ConOut parsing.
>>> 
>>> We could have the same effect defaulting to Video. This bug should have 
>>> been discussed / reviewed before it was committed.
>> 
>> How is is different from defaulting to serial, it is just as bad? we can not 
>> guess there, thats why we do have ConOutDev list.
>> 
>> 
>>> 
>>> If it would appear, there are systems with unusable devices listed in 
>>> ConOutDev, then we need to think how to handle such case.
>>> 
>>> Yes. We fall back to the arbitrary device... It's just a flag that can be 
>>> overridden. We can easily fall back to video too.
>> 
>> We *should not* fall back on arbitrary devices when there is source for 
>> alternate options. And that option is from specification:
>> 
>> "The ConInDev, ConOutDev, and ErrOutDev variables each contain an 
>> EFI_DEVICE_PATH_PROTOCOL descriptor that defines all the possible default 
>> devices to use on boot. These variables are volatile, and are set 
>> dynamically on every boot. ConIn, ConOut, and ErrOut are always proper 
>> subsets of ConInDev, ConOutDev, and ErrOutDev.”
>> 
>> Right. Except they aren't a proper subset in this case. Since they aren't a 
>> proper subset, can you count on them having any meaningful meaning? In the 
>> cases you found they do, but it's just as arbitrary.
> 
> Well, we can argue if empty set is or is not subset of (any) other set. But, 
> we do have specification. And we should not arbitrary pick what part we are 
> going to follow and what not.
> 
> The empty set isn't a proper subset. It is a subset, but not a proper subset, 
> by definition. Therefore, it's not standards complaint.

The empty set is a proper subset of any non-empty set. Proper just means that 
it's not equal to the original set. Perhaps you're thinking of trivial subsets 
(which are the empty set and, if not empty, the original set)?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: af366d353b84 - main - amd64: implement strlen in assembly

2021-02-08 Thread Jessica Clarke
On 8 Feb 2021, at 19:15, Mateusz Guzik  wrote:
> 
> The branch main has been updated by mjg:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=af366d353b84bdc4e730f0fc563853abc338271c
> 
> commit af366d353b84bdc4e730f0fc563853abc338271c
> Author: Mateusz Guzik 
> AuthorDate: 2021-02-08 17:01:48 +
> Commit: Mateusz Guzik 
> CommitDate: 2021-02-08 19:15:21 +
> 
>amd64: implement strlen in assembly
> 
>The C variant in libkern performs excessive branching to find the
>non-zero byte instead of using the bsfq instruction. The same code
>patched to use it is still slower than the routine implemented here
>as the compiler keeps neglecting to perform certain optimizations
>(like using leaq).
> 
>On top of that the routine can is a starting point for copyinstr
>which operates on words instead of bytes.
> 
>Tested with glibc test suite.
> 
>Sample results (calls/s):
> 
>Haswell:
>$(perl -e "print 'A' x 3"):
>stock:  211198039
>patched:338626619
>asm:465609618
> 
>$(perl -e "print 'A' x 100"):
>stock:   83151997
>patched: 98285919
>asm:120719888
> 
>AMD EPYC 7R32:
>$(perl -e "print 'A' x 3"):
>stock:  282523617
>asm:491498172
> 
>$(perl -e "print 'A' x 100"):
>stock:  114857172
>asm:112082057

No Reviewed by? More than one pair of eyes on non-trivial assembly is
almost always a good idea.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 81e074d57dfc - main - libkern: use compiler builtins for strcpy, strcmp and strlen

2021-02-08 Thread Jessica Clarke
On 8 Feb 2021, at 19:15, Mateusz Guzik  wrote:
> 
> The branch main has been updated by mjg:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=81e074d57dfcd86f152e2848dc44b77087ee7a2d
> 
> commit 81e074d57dfcd86f152e2848dc44b77087ee7a2d
> Author: Mateusz Guzik 
> AuthorDate: 2021-02-07 19:50:25 +
> Commit: Mateusz Guzik 
> CommitDate: 2021-02-08 19:15:21 +
> 
>libkern: use compiler builtins for strcpy, strcmp and strlen

Why?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: af366d353b84 - main - amd64: implement strlen in assembly

2021-02-08 Thread Jessica Clarke
> On 8 Feb 2021, at 23:13, Kevin Bowling  wrote:
> 
> FreeBSD does not require pre-commit approval unless called out
> specifically.  Are you volunteering to review the changes, and if so
> where is your guidance?  These messages are otherwise unhelpful.

It is not a hard requirement, but it is strongly encouraged. Section 7
of the committer's guide says:

• All non-trivial changes should be reviewed before they are
committed to the repository.

This was a non-trivial change. I was particularly frustrated to see
this commit go in without review having previously called out mjg@ for
not getting any reviews for his (now reverted) previous strlen change.

Jess

> On Mon, Feb 8, 2021 at 12:37 PM Jessica Clarke  wrote:
>> 
>> On 8 Feb 2021, at 19:15, Mateusz Guzik  wrote:
>>> 
>>> The branch main has been updated by mjg:
>>> 
>>> URL: 
>>> https://cgit.FreeBSD.org/src/commit/?id=af366d353b84bdc4e730f0fc563853abc338271c
>>> 
>>> commit af366d353b84bdc4e730f0fc563853abc338271c
>>> Author: Mateusz Guzik 
>>> AuthorDate: 2021-02-08 17:01:48 +
>>> Commit: Mateusz Guzik 
>>> CommitDate: 2021-02-08 19:15:21 +
>>> 
>>>   amd64: implement strlen in assembly
>>> 
>>>   The C variant in libkern performs excessive branching to find the
>>>   non-zero byte instead of using the bsfq instruction. The same code
>>>   patched to use it is still slower than the routine implemented here
>>>   as the compiler keeps neglecting to perform certain optimizations
>>>   (like using leaq).
>>> 
>>>   On top of that the routine can is a starting point for copyinstr
>>>   which operates on words instead of bytes.
>>> 
>>>   Tested with glibc test suite.
>>> 
>>>   Sample results (calls/s):
>>> 
>>>   Haswell:
>>>   $(perl -e "print 'A' x 3"):
>>>   stock:  211198039
>>>   patched:338626619
>>>   asm:465609618
>>> 
>>>   $(perl -e "print 'A' x 100"):
>>>   stock:   83151997
>>>   patched: 98285919
>>>   asm:120719888
>>> 
>>>   AMD EPYC 7R32:
>>>   $(perl -e "print 'A' x 3"):
>>>   stock:  282523617
>>>   asm:491498172
>>> 
>>>   $(perl -e "print 'A' x 100"):
>>>   stock:  114857172
>>>   asm:112082057
>> 
>> No Reviewed by? More than one pair of eyes on non-trivial assembly is
>> almost always a good idea.
>> 
>> Jess
>> 
>> ___
>> dev-commits-src-m...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main
>> To unsubscribe, send any mail to 
>> "dev-commits-src-main-unsubscr...@freebsd.org"

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 81e074d57dfc - main - libkern: use compiler builtins for strcpy, strcmp and strlen

2021-02-08 Thread Jessica Clarke
On 8 Feb 2021, at 22:08, Alexander Richardson  wrote:
> 
> On Mon, 8 Feb 2021, 19:37 Jessica Clarke,  wrote:
>> On 8 Feb 2021, at 19:15, Mateusz Guzik  wrote:
>> > 
>> > The branch main has been updated by mjg:
>> > 
>> > URL: 
>> > https://cgit.FreeBSD.org/src/commit/?id=81e074d57dfcd86f152e2848dc44b77087ee7a2d
>> > 
>> > commit 81e074d57dfcd86f152e2848dc44b77087ee7a2d
>> > Author: Mateusz Guzik 
>> > AuthorDate: 2021-02-07 19:50:25 +
>> > Commit: Mateusz Guzik 
>> > CommitDate: 2021-02-08 19:15:21 +
>> > 
>> >libkern: use compiler builtins for strcpy, strcmp and strlen
>> 
>> Why?
> 
> 
> I guess because the kernel uses -ffreestanding, so the libcall inlining 
> optimization requires explicit uses of __builtin_foo

That would make sense, but such info belongs in the commit message, a
comment or both... As it stands the message is not useful as anyone can
see from reading the diff that that's what it does.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: af366d353b84 - main - amd64: implement strlen in assembly

2021-02-09 Thread Jessica Clarke
Here's your review after reading through it for <5 minutes today:

On 8 Feb 2021, at 19:15, Mateusz Guzik  wrote:
> + leaq(%r11,%r8),%rcx
> + notq%r11
> + andq%r11,%rcx
> + andq%r9,%rcx
> ...
> + leaq(%r11,%r8),%rcx
> + notq%r11
> + andq%rcx,%r11

These look the wrong way round (but you got it the right way round
above).

> + andq%r9,%rcx

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 5a4333a5378f - main - This takes Warners suggested approach to making it so that platforms that for whatever reason cannot include the RATELIMIT option can still work with rack. It adds two d

2021-05-07 Thread Jessica Clarke
On 7 May 2021, at 22:34, Randall Stewart  wrote:
> 
> The branch main has been updated by rrs:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=5a4333a5378f7afe4f8cab293a987865ae0c32c4
> 
> commit 5a4333a5378f7afe4f8cab293a987865ae0c32c4
> Author: Randall Stewart 
> AuthorDate: 2021-05-07 21:32:32 +
> Commit: Randall Stewart 
> CommitDate: 2021-05-07 21:32:32 +
> 
>This takes Warners suggested approach to making it so that
>platforms that for whatever reason cannot include the RATELIMIT option
>can still work with rack. It adds two dummy functions that rack will
>call and find out that the highest hw supported b/w is 0 (which
>kinda makes sense and rack is already prepared to handle).

Hi Randall,
Could you please start writing a proper separate subject line for your git
commits? This is not best practice, and many tools behave poorly in the
presence of one big paragraph at the start rather than a separate subject line,
including the email hook here. See [1] for FreeBSD’s own guide on the matter.

Jess

[1] https://docs.freebsd.org/en/articles/committers-guide/#commit-log-message

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: e73e2ee0acf5 - main - cxgbei: Handle target transfers with excess unsolicited data.

2021-05-15 Thread Jessica Clarke
On 15 May 2021, at 21:56, Mateusz Guzik  wrote:
> 
> One of these commits breaks tinderbox:
> i386 MINIMAL kernel failed, check _.i386.MINIMAL for details
> i386 GENERIC kernel failed, check _.i386.GENERIC for details
> i386 GENERIC-NODEBUG kernel failed, check _.i386.GENERIC-NODEBUG for details
> i386 PAE kernel failed, check _.i386.PAE for details
> i386 LINT kernel failed, check _.i386.LINT for details
> i386 LINT-NOINET kernel failed, check _.i386.LINT-NOINET for details
> i386 LINT-NOINET6 kernel failed, check _.i386.LINT-NOINET6 for details
> i386 LINT-NOIP kernel failed, check _.i386.LINT-NOIP for details
> 
> /usr/src/sys/dev/cxgbe/tom/t4_ddp.c:1045:15: error: invalid operands
> to binary expression ('void *' and 'int')
>start_pva = trunc_page(sgl->addr);
>^
> ./machine/param.h:150:29: note: expanded from macro 'trunc_page'
> #define trunc_page(x)   ((x) & ~PAGE_MASK)
> ~~~ ^ ~~
> /usr/src/sys/dev/cxgbe/tom/t4_ddp.c:1300:8: error: invalid operands to
> binary expression ('void *' and 'int')
>pva = trunc_page(sgl->addr);
>  ^
> ./machine/param.h:150:29: note: expanded from macro 'trunc_page'
> #define trunc_page(x)   ((x) & ~PAGE_MASK)
> ~~~ ^ ~~

It seems amd64, arm64 and riscv cast to unsigned long first, but arm, i386,
mips and powerpc do not. These macros should probably just become MI in
sys/sys/param.h rather than fixing the MD copies to include casts.

Jess

> On 5/14/21, John Baldwin  wrote:
>> The branch main has been updated by jhb:
>> 
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=e73e2ee0acf5a0e0f47b9c2bcd73c835c4922fab
>> 
>> commit e73e2ee0acf5a0e0f47b9c2bcd73c835c4922fab
>> Author: John Baldwin 
>> AuthorDate: 2021-05-14 19:20:57 +
>> Commit: John Baldwin 
>> CommitDate: 2021-05-14 19:21:34 +
>> 
>>cxgbei: Handle target transfers with excess unsolicited data.
>> 
>>The CTL frontend might have provided a buffer that is smaller than the
>>FirstBurstLength and thus smaller than the amount of unsolicited data
>>included in the request PDU.  Treat these transfers as an empty
>>transfer.
>> 
>>Reported by:Jithesh Arakkan @ Chelsio
>>Sponsored by:   Chelsio Communications
>> 
>>Differential Revision:  https://reviews.freebsd.org/D29940
>> ---
>> sys/dev/cxgbe/cxgbei/icl_cxgbei.c | 9 +++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>> 
>> diff --git a/sys/dev/cxgbe/cxgbei/icl_cxgbei.c
>> b/sys/dev/cxgbe/cxgbei/icl_cxgbei.c
>> index 7f638c96483a..c4eb4a35ad31 100644
>> --- a/sys/dev/cxgbe/cxgbei/icl_cxgbei.c
>> +++ b/sys/dev/cxgbe/cxgbei/icl_cxgbei.c
>> @@ -1064,10 +1064,15 @@ icl_cxgbei_conn_transfer_setup(struct icl_conn *ic,
>> union ctl_io *io,
>>  /*
>>   * Note that ICL calls conn_transfer_setup even if the first
>>   * burst had everything and there's nothing left to transfer.
>> + *
>> + * NB: The CTL frontend might have provided a buffer
>> + * whose length (kern_data_len) is smaller than the
>> + * FirstBurstLength of unsolicited data.  Treat those
>> + * as an empty transfer.
>>   */
>> -MPASS(ctsio->kern_data_len >= first_burst);
>>  xferlen = ctsio->kern_data_len;
>> -if (xferlen - first_burst < ci->ddp_threshold) {
>> +if (xferlen < first_burst ||
>> +xferlen - first_burst < ci->ddp_threshold) {
>> no_ddp:
>>  /*
>>   * No DDP for this transfer.  Allocate a TTT (based on
>> 
> 
> 
> -- 
> Mateusz Guzik 
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: effc8e57fbf0 - main - libalias: Style cleanup

2021-05-15 Thread Jessica Clarke
On 15 May 2021, at 23:36, Lutz Donnerhacke  wrote:
> 
> On Sun, May 16, 2021 at 12:30:54AM +0300, Konstantin Belousov wrote:
>>> The LIBALIAS_LOCK_ASSERT and the variable declarations were not moved.
>> So you changed some style, but left the large violation in place.
> 
> This cleanup is a preparation to fix various issues in this code.
> So yes, the change was intentionally limited to style issues.
> 
> Mixing style and functional changes makes it very hard to track down a
> broken behavior to a single commit.  This change is huge, it must not break
> anything.

I think you two are talking past each other. kib@’s point is that some of the
changes made in this commit were style *changes* not style *fixes* (i.e. the
code was compliant before, you’ve just changed it from one acceptable
formatting to another), and that there were instances of significant style
violations *not* fixed (e.g. the assertion macro before variable declarations
pointed out). He is not talking about functional violations, only style ones.
However, in your defence, your original commit did not claim to fix *all* style
violations, only "most annoying style errors", though that doesn’t account for
unnecessary churn as seen with the blank lines at the starts of functions.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 086feed850c3 - main - md5: Create md5sum, etc compatible programs

2021-05-19 Thread Jessica Clarke
On 19 May 2021, at 18:44, Warner Losh  wrote:
> 
> The branch main has been updated by imp:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=086feed850c31c278f25c958b97992d024139896
> 
> commit 086feed850c31c278f25c958b97992d024139896
> Author: Warner Losh 
> AuthorDate: 2021-05-19 17:26:20 +
> Commit: Warner Losh 
> CommitDate: 2021-05-19 17:41:53 +
> 
>md5: Create md5sum, etc compatible programs
> 
>On Linux, there's a similar set of programs to ours, but that end in the
>letters 'sum'. These act basically like FreeBSD versions run with the -r
>option. Add code so that when the program ends in 'sum' you get the
>linux -r behavior. This is enough to make most things that use sha*sum
>work correctly (the -c / --check options, as well as the long args are
>not implemented). When running with the -sum programs, ignore -t instead
>of running internal speed tests and make -c an error.
> 
>Reviewed by:sef, and kp and allanjude (earlier version)
>Relnotes:   yes
>Sponsored by:   Netflix
>Differential Revision:  https://reviews.freebsd.org/D30309
> ---
> diff --git a/sbin/md5/md5.c b/sbin/md5/md5.c
> index 96dfcede9711..4381ef124c7b 100644
> --- a/sbin/md5/md5.c
> +++ b/sbin/md5/md5.c
> @@ -177,13 +177,32 @@ main(int argc, char *argv[])
>   charbuf[HEX_DIGEST_LENGTH];
>   size_t  len;
>   unsigneddigest;
> - const char* progname;
> + char*progname;
> + boolgnu_emu = false;

This file doesn’t currently include stdbool.h explicitly, and apparently that
is not implicitly included by any of the headers on Linux (and I cannot work
out where it comes from on FreeBSD). Could you please add the explicit include
to fix cross-building?

Thanks,
Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: d0ea5e467f3c - main - md5: portability fix -- include stdbool.h explicitly

2021-05-20 Thread Jessica Clarke
=On 20 May 2021, at 18:30, Warner Losh  wrote:
> 
> The branch main has been updated by imp:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=d0ea5e467f3c44909667c5ee90c3d26653fb6687
> 
> commit d0ea5e467f3c44909667c5ee90c3d26653fb6687
> Author: Warner Losh 
> AuthorDate: 2021-05-20 17:26:46 +
> Commit: Warner Losh 
> CommitDate: 2021-05-20 17:28:18 +
> 
>md5: portability fix -- include stdbool.h explicitly
> 
>stdbool.h needs to be included to use type bool variables. Due to
>namespace pollution, this gets brought in on FreeBSD, but not on
>other systems. Include it explicilty.

Thanks!

>Noticed by: arichards@

For once a cross-building issue not reported by Alex, though still
Cambridge :)

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: af949c590bd8 - main - Disable stack gap for ntpd during build.

2021-05-21 Thread Jessica Clarke
On 21 May 2021, at 14:34, Marcin Wojtas  wrote:
> 
> The branch main has been updated by mw:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=af949c590bd8a00a5973b5875d7e0fa6832ea64a
> 
> commit af949c590bd8a00a5973b5875d7e0fa6832ea64a
> Author: Marcin Wojtas 
> AuthorDate: 2021-05-21 09:29:22 +
> Commit: Marcin Wojtas 
> CommitDate: 2021-05-21 13:33:06 +
> 
>Disable stack gap for ntpd during build.
> 
>When starting, ntpd calls setrlimit(2) to limit maximum size of its
>stack. The stack limit chosen by ntpd is 200K, so when stack gap
>is enabled, the stack gap is larger than this limit, which results
>in ntpd crashing.

Isn’t the bug that the unusable gap counts as usage?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: af949c590bd8 - main - Disable stack gap for ntpd during build.

2021-05-21 Thread Jessica Clarke
> On 21 May 2021, at 15:11, Marcin Wojtas  wrote:
> 
> Hi Jess
> 
> pt., 21 maj 2021 o 15:39 Jessica Clarke  napisał(a):
>> 
>> On 21 May 2021, at 14:34, Marcin Wojtas  wrote:
>>> 
>>> The branch main has been updated by mw:
>>> 
>>> URL: 
>>> https://cgit.FreeBSD.org/src/commit/?id=af949c590bd8a00a5973b5875d7e0fa6832ea64a
>>> 
>>> commit af949c590bd8a00a5973b5875d7e0fa6832ea64a
>>> Author: Marcin Wojtas 
>>> AuthorDate: 2021-05-21 09:29:22 +
>>> Commit: Marcin Wojtas 
>>> CommitDate: 2021-05-21 13:33:06 +
>>> 
>>>   Disable stack gap for ntpd during build.
>>> 
>>>   When starting, ntpd calls setrlimit(2) to limit maximum size of its
>>>   stack. The stack limit chosen by ntpd is 200K, so when stack gap
>>>   is enabled, the stack gap is larger than this limit, which results
>>>   in ntpd crashing.
>> 
>> Isn’t the bug that the unusable gap counts as usage?
>> 
>> Jess
>> 
> 
> An alternative solution was submitted
> (https://reviews.freebsd.org/D29832), so that to extend the limit for
> ntpd, but eventually it was recommended to simple disable the stack
> gap for it until it's fixed upstream (see the last comment in the
> linked revision).

That’s my point, there is nothing to “fix” upstream. NTPD uses less than 200K
of stack, thus it is perfectly reasonable for it to set its limit to that. The
fact that FreeBSD decides to count an arbitrary, non-deterministic amount of
additional unusable virtual address space towards that limit is not its fault,
but a bug in FreeBSD that needs to be fixed as it’s entirely unreasonable for
applications to have to account for that.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 5e912f5fec02 - main - aic7xxx: Fix re-building firmware with -fno-common

2021-05-28 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=5e912f5fec025766521f535d1237330ede7f18e2

commit 5e912f5fec025766521f535d1237330ede7f18e2
Author: Jessica Clarke 
AuthorDate: 2021-05-28 18:07:17 +
Commit: Jessica Clarke 
CommitDate: 2021-05-28 18:07:17 +

aic7xxx: Fix re-building firmware with -fno-common

The generated C output for aicasm_scan.l defines yylineno already, so
references to it from other files should use an extern declaration.

The STAILQ_HEAD use in aicasm_symbol.h also provided an identifier,
causing it to both define the struct type and define a variable of that
struct type, causing any C file including the header to define the same
variable. This variable is not used (and confusingly clashes with a
field name just below) and was likely caused by confusion when switching
between defining fields using similar type macros and defining the type
itself.

Reviewed by:imp
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D30525
---
 sys/dev/aic7xxx/aicasm/aicasm_gram.y   | 2 +-
 sys/dev/aic7xxx/aicasm/aicasm_symbol.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sys/dev/aic7xxx/aicasm/aicasm_gram.y 
b/sys/dev/aic7xxx/aicasm/aicasm_gram.y
index c479c8fdf2db..d32793f4c12b 100644
--- a/sys/dev/aic7xxx/aicasm/aicasm_gram.y
+++ b/sys/dev/aic7xxx/aicasm/aicasm_gram.y
@@ -59,7 +59,7 @@
 #include "aicasm_symbol.h"
 #include "aicasm_insformat.h"
 
-int yylineno;
+extern int yylineno;
 char *yyfilename;
 char stock_prefix[] = "aic_";
 char *prefix = stock_prefix;
diff --git a/sys/dev/aic7xxx/aicasm/aicasm_symbol.h 
b/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
index 616dfd28fdeb..a15fa12176d1 100644
--- a/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
+++ b/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
@@ -110,7 +110,7 @@ struct macro_arg {
regex_t arg_regex;
char   *replacement_text;
 };
-STAILQ_HEAD(macro_arg_list, macro_arg) args;
+STAILQ_HEAD(macro_arg_list, macro_arg);
 
 struct macro_info {
struct macro_arg_list args;
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 91abbc4993a5 - main - [mips/broadcom] set sysctl "hw.model" by SoC ChipCommon ID

2021-05-28 Thread Jessica Clarke
On 28 May 2021, at 21:36, Michael Zhilin  wrote:
> 
> The branch main has been updated by mizhka:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=91abbc4993a5964badd21bc691ae273a1a2d9c20
> 
> commit 91abbc4993a5964badd21bc691ae273a1a2d9c20
> Author: Michael Zhilin 
> AuthorDate: 2021-05-28 20:32:30 +
> Commit: Michael Zhilin 
> CommitDate: 2021-05-28 20:35:37 +
> 
>[mips/broadcom] set sysctl "hw.model" by SoC ChipCommon ID
> 
>Small patch to set "hw.model" by SoC ChipCommon ID. On BCM4718 it will be 
> BCM4716, because 4716 is core for 4716,4717 & 4718.
> 
>Tested on Netgear WNR3500L (BCM4718) and Asus RT-N53 (BCM5357).
> 
>Reviewed by: landonf, yamori...@yahoo.co.jp
>Sponsored by: Postgres Professional
>Differential revision: https://reviews.freebsd.org/D12737
> ---
> sys/mips/broadcom/bcm_machdep.c | 9 +
> 1 file changed, 9 insertions(+)
> 
> diff --git a/sys/mips/broadcom/bcm_machdep.c b/sys/mips/broadcom/bcm_machdep.c
> index 20ae22f2e9b0..581fffdd899d 100644
> --- a/sys/mips/broadcom/bcm_machdep.c
> +++ b/sys/mips/broadcom/bcm_machdep.c
> @@ -116,6 +116,9 @@ static int
> bcm_erom_probe_and_attach(bhnd_erom_class_t **erom_cls,
> extern int*edata;
> extern int*end;
> 
> +/* from sys/mips/mips/machdep.c */
> +extern char  cpu_model[];

This should already be declared by machine/md_var.h.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: e5f5b6a75c0a - main - .github: Attempt to un-break Clang 9 action

2021-05-28 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=e5f5b6a75c0aa0f51a399e2002d15b51211630b5

commit e5f5b6a75c0aa0f51a399e2002d15b51211630b5
Author: Jessica Clarke 
AuthorDate: 2021-05-29 03:36:36 +
Commit: Jessica Clarke 
CommitDate: 2021-05-29 03:36:36 +

.github: Attempt to un-break Clang 9 action

GitHub removed Clang 9 from the 20.04 image[1], breaking this build.
Thus, manually add the specific versioned packages we need for the
Ubuntu jobs to ensure they're installed. Note that we don't do the same
for macOS, as Homebrew does not allow multiple llvm@N to co-exist,
giving an error if you attempt to install a second one. In practice we
don't actually use the compiler field here for anything other than the
build name, it's only the cross-bindir that matters, so when it
eventually moves to 12 the name will get confusing but the job will
still work.

MFC after:  immediately

[1] 
https://github.com/actions/virtual-environments/commit/15a610677be406d250c1f6732b03c8b87e693a0a
---
 .github/workflows/cross-bootstrap-tools.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/cross-bootstrap-tools.yml 
b/.github/workflows/cross-bootstrap-tools.yml
index f002cb0fbbe2..22aa1065d44b 100644
--- a/.github/workflows/cross-bootstrap-tools.yml
+++ b/.github/workflows/cross-bootstrap-tools.yml
@@ -18,11 +18,11 @@ jobs:
   - os: ubuntu-20.04
 compiler: clang-9
 cross-bindir: /usr/lib/llvm-9/bin
-pkgs: bmake libarchive-dev
+pkgs: bmake libarchive-dev clang-9 lld-9
   - os: ubuntu-20.04
 compiler: clang-10
 cross-bindir: /usr/lib/llvm-10/bin
-pkgs: bmake libarchive-dev
+pkgs: bmake libarchive-dev clang-10 lld-10
   - os: macOS-latest
 compiler: clang-11
 pkgs: bmake libarchive
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: ddd0a8bffe35 - stable/13 - .github: Attempt to un-break Clang 9 action

2021-05-28 Thread Jessica Clarke
The branch stable/13 has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=ddd0a8bffe35fce60e71147d3789564ad1997ba3

commit ddd0a8bffe35fce60e71147d3789564ad1997ba3
Author: Jessica Clarke 
AuthorDate: 2021-05-29 03:36:36 +
Commit: Jessica Clarke 
CommitDate: 2021-05-29 03:38:07 +

.github: Attempt to un-break Clang 9 action

GitHub removed Clang 9 from the 20.04 image[1], breaking this build.
Thus, manually add the specific versioned packages we need for the
Ubuntu jobs to ensure they're installed. Note that we don't do the same
for macOS, as Homebrew does not allow multiple llvm@N to co-exist,
giving an error if you attempt to install a second one. In practice we
don't actually use the compiler field here for anything other than the
build name, it's only the cross-bindir that matters, so when it
eventually moves to 12 the name will get confusing but the job will
still work.

MFC after:  immediately

[1] 
https://github.com/actions/virtual-environments/commit/15a610677be406d250c1f6732b03c8b87e693a0a

(cherry picked from commit e5f5b6a75c0aa0f51a399e2002d15b51211630b5)
---
 .github/workflows/cross-bootstrap-tools.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.github/workflows/cross-bootstrap-tools.yml 
b/.github/workflows/cross-bootstrap-tools.yml
index f002cb0fbbe2..22aa1065d44b 100644
--- a/.github/workflows/cross-bootstrap-tools.yml
+++ b/.github/workflows/cross-bootstrap-tools.yml
@@ -18,11 +18,11 @@ jobs:
   - os: ubuntu-20.04
 compiler: clang-9
 cross-bindir: /usr/lib/llvm-9/bin
-pkgs: bmake libarchive-dev
+pkgs: bmake libarchive-dev clang-9 lld-9
   - os: ubuntu-20.04
 compiler: clang-10
 cross-bindir: /usr/lib/llvm-10/bin
-pkgs: bmake libarchive-dev
+pkgs: bmake libarchive-dev clang-10 lld-10
   - os: macOS-latest
 compiler: clang-11
 pkgs: bmake libarchive
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 5a20c351ea45 - main - [skip ci] add a CODEOWNERS file

2021-05-31 Thread Jessica Clarke
On 31 May 2021, at 20:16, Warner Losh  wrote:
> 
> 
> 
> On Mon, May 31, 2021, 1:11 PM Ed Maste  wrote:
> On Mon, 31 May 2021 at 11:51, Alan Somers  wrote:
> >
> >>
> >> I think this file isn't the right place for (another copy of) this
> >> text; perhaps the CODEOWNERS file should just reference the top-level
> >> MAINTAINERS?
> >
> > Except that CODEOWNERS is in a format that tools know how to parse.  If 
> > anything, MAINTAINERS should be a symlink to CODEOWNERS.
> 
> At least the file's location and user IDs suggest that it is specific
> to GitHub; in any case I don't really care which one points to which.
> I hope we can agree though that we don't really want two different
> files representing code ownership in different ways that both
> independently refer to a third mechanism for recording code ownership
> that's external to the source tree?
> 
> It also works on gitlab, FWIW. The format is standard. Bummer we can't 
> generate it based on where it is published…

We could conceivably have a CODEOWNERS.master from which the others can be 
generated via `make codeowners` whenever someone edits it. Whether that’s worth 
the hassle of implementing though for a file that shouldn’t regularly be 
changing is unclear.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 5a20c351ea45 - main - [skip ci] add a CODEOWNERS file

2021-05-31 Thread Jessica Clarke
On 31 May 2021, at 20:37, Warner Losh  wrote:
> 
> 
> 
> On Mon, May 31, 2021 at 1:21 PM Jessica Clarke  wrote:
> On 31 May 2021, at 20:16, Warner Losh  wrote:
> > 
> > 
> > 
> > On Mon, May 31, 2021, 1:11 PM Ed Maste  wrote:
> > On Mon, 31 May 2021 at 11:51, Alan Somers  wrote:
> > >
> > >>
> > >> I think this file isn't the right place for (another copy of) this
> > >> text; perhaps the CODEOWNERS file should just reference the top-level
> > >> MAINTAINERS?
> > >
> > > Except that CODEOWNERS is in a format that tools know how to parse.  If 
> > > anything, MAINTAINERS should be a symlink to CODEOWNERS.
> > 
> > At least the file's location and user IDs suggest that it is specific
> > to GitHub; in any case I don't really care which one points to which.
> > I hope we can agree though that we don't really want two different
> > files representing code ownership in different ways that both
> > independently refer to a third mechanism for recording code ownership
> > that's external to the source tree?
> > 
> > It also works on gitlab, FWIW. The format is standard. Bummer we can't 
> > generate it based on where it is published…
> 
> We could conceivably have a CODEOWNERS.master from which the others can be 
> generated via `make codeowners` whenever someone edits it. Whether that’s 
> worth the hassle of implementing though for a file that shouldn’t regularly 
> be changing is unclear.
> 
> Doing that's trivial... However, it would mean that the automatic flagging 
> that this file's presence gives wouldn't work... But then again, there's no 
> issues or pull requests at the gitlab mirror, so at the moment it's a bit of 
> a moot point.

A hypothetical .gitlab/CODEOWNERS would be checked in as a generated file, if 
that was unclear. Otherwise I’m not sure I understand your first point?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 5a20c351ea45 - main - [skip ci] add a CODEOWNERS file

2021-05-31 Thread Jessica Clarke
On 31 May 2021, at 20:50, Alan Somers  wrote:
> 
> On Mon, May 31, 2021 at 1:39 PM Jessica Clarke  wrote:
> On 31 May 2021, at 20:37, Warner Losh  wrote:
> > 
> > 
> > 
> > On Mon, May 31, 2021 at 1:21 PM Jessica Clarke  wrote:
> > On 31 May 2021, at 20:16, Warner Losh  wrote:
> > > 
> > > 
> > > 
> > > On Mon, May 31, 2021, 1:11 PM Ed Maste  wrote:
> > > On Mon, 31 May 2021 at 11:51, Alan Somers  wrote:
> > > >
> > > >>
> > > >> I think this file isn't the right place for (another copy of) this
> > > >> text; perhaps the CODEOWNERS file should just reference the top-level
> > > >> MAINTAINERS?
> > > >
> > > > Except that CODEOWNERS is in a format that tools know how to parse.  If 
> > > > anything, MAINTAINERS should be a symlink to CODEOWNERS.
> > > 
> > > At least the file's location and user IDs suggest that it is specific
> > > to GitHub; in any case I don't really care which one points to which.
> > > I hope we can agree though that we don't really want two different
> > > files representing code ownership in different ways that both
> > > independently refer to a third mechanism for recording code ownership
> > > that's external to the source tree?
> > > 
> > > It also works on gitlab, FWIW. The format is standard. Bummer we can't 
> > > generate it based on where it is published…
> > 
> > We could conceivably have a CODEOWNERS.master from which the others can be 
> > generated via `make codeowners` whenever someone edits it. Whether that’s 
> > worth the hassle of implementing though for a file that shouldn’t regularly 
> > be changing is unclear.
> > 
> > Doing that's trivial... However, it would mean that the automatic flagging 
> > that this file's presence gives wouldn't work... But then again, there's no 
> > issues or pull requests at the gitlab mirror, so at the moment it's a bit 
> > of a moot point.
> 
> A hypothetical .gitlab/CODEOWNERS would be checked in as a generated file, if 
> that was unclear. Otherwise I’m not sure I understand your first point?
> 
> Jess
> 
> There's no need to generate anything.  Both github and gitlab support a 
> CODEOWNERS file in the project's root.  Let's just move it there.  We can 
> delete the old MAINTAINERS, too, once all of its entries have been converted.

Not if people have different usernames between FreeBSD, GitHub and GitLab? Or 
can it work off email addresses and we can rely on people adding their 
@FreeBSD.org to their account? Though that still doesn’t work for groups.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 18f55c67f746 - main - x86: Fix lapic_ipi_alloc() on i386

2021-05-31 Thread Jessica Clarke
On 1 Jun 2021, at 00:09, Mark Johnston  wrote:
> 
> The branch main has been updated by markj:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=18f55c67f746f0ad12fe972328234d340a621df9
> 
> commit 18f55c67f746f0ad12fe972328234d340a621df9
> Author: Mark Johnston 
> AuthorDate: 2021-05-31 22:51:14 +
> Commit: Mark Johnston 
> CommitDate: 2021-05-31 22:51:14 +
> 
>x86: Fix lapic_ipi_alloc() on i386
> 
>The loop which checks to see if "dynamic" IDT entries are allocated
>needs to compare with the trampoline address of the reserved ISR.
>Otherwise it will never succeed.
> 
>Reported by:Harry Schmalzbauer 
>Tested by:  Harry Schmalzbauer 
>Reviewed by:kib
>MFC after:  1 week
>Sponsored by:   The FreeBSD Foundation
>Differential Revision:  https://reviews.freebsd.org/D30576
> ---
> sys/x86/x86/local_apic.c | 10 ++
> 1 file changed, 10 insertions(+)
> 
> diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c
> index 5b4910d4b891..bb575d0c601d 100644
> --- a/sys/x86/x86/local_apic.c
> +++ b/sys/x86/x86/local_apic.c
> @@ -2127,6 +2127,10 @@ native_lapic_ipi_vectored(u_int vector, int dest)
> 
> #endif /* SMP */
> 
> +#ifdef __i386__
> +extern uintptr_t setidt_disp;

uintptr_t here is fishy. Should it not be size_t or ptrdiff_t?

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 36da5710d3e4 - stable/13 - aic7xxx: Fix re-building firmware with -fno-common

2021-06-03 Thread Jessica Clarke
The branch stable/13 has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=36da5710d3e4b3e3412ef7e4826506f9d64b0b35

commit 36da5710d3e4b3e3412ef7e4826506f9d64b0b35
Author: Jessica Clarke 
AuthorDate: 2021-05-28 18:07:17 +
Commit: Jessica Clarke 
CommitDate: 2021-06-04 00:28:15 +

aic7xxx: Fix re-building firmware with -fno-common

The generated C output for aicasm_scan.l defines yylineno already, so
references to it from other files should use an extern declaration.

The STAILQ_HEAD use in aicasm_symbol.h also provided an identifier,
causing it to both define the struct type and define a variable of that
struct type, causing any C file including the header to define the same
variable. This variable is not used (and confusingly clashes with a
field name just below) and was likely caused by confusion when switching
between defining fields using similar type macros and defining the type
itself.

Reviewed by:imp
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D30525

(cherry picked from commit 5e912f5fec025766521f535d1237330ede7f18e2)
---
 sys/dev/aic7xxx/aicasm/aicasm_gram.y   | 2 +-
 sys/dev/aic7xxx/aicasm/aicasm_symbol.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sys/dev/aic7xxx/aicasm/aicasm_gram.y 
b/sys/dev/aic7xxx/aicasm/aicasm_gram.y
index c479c8fdf2db..d32793f4c12b 100644
--- a/sys/dev/aic7xxx/aicasm/aicasm_gram.y
+++ b/sys/dev/aic7xxx/aicasm/aicasm_gram.y
@@ -59,7 +59,7 @@
 #include "aicasm_symbol.h"
 #include "aicasm_insformat.h"
 
-int yylineno;
+extern int yylineno;
 char *yyfilename;
 char stock_prefix[] = "aic_";
 char *prefix = stock_prefix;
diff --git a/sys/dev/aic7xxx/aicasm/aicasm_symbol.h 
b/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
index 616dfd28fdeb..a15fa12176d1 100644
--- a/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
+++ b/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
@@ -110,7 +110,7 @@ struct macro_arg {
regex_t arg_regex;
char   *replacement_text;
 };
-STAILQ_HEAD(macro_arg_list, macro_arg) args;
+STAILQ_HEAD(macro_arg_list, macro_arg);
 
 struct macro_info {
struct macro_arg_list args;
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 5e478926f04a - stable/12 - aic7xxx: Fix re-building firmware with -fno-common

2021-06-03 Thread Jessica Clarke
The branch stable/12 has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=5e478926f04a8ad0c2401744bcb477e363ea97f9

commit 5e478926f04a8ad0c2401744bcb477e363ea97f9
Author: Jessica Clarke 
AuthorDate: 2021-05-28 18:07:17 +
Commit: Jessica Clarke 
CommitDate: 2021-06-04 00:28:45 +

aic7xxx: Fix re-building firmware with -fno-common

The generated C output for aicasm_scan.l defines yylineno already, so
references to it from other files should use an extern declaration.

The STAILQ_HEAD use in aicasm_symbol.h also provided an identifier,
causing it to both define the struct type and define a variable of that
struct type, causing any C file including the header to define the same
variable. This variable is not used (and confusingly clashes with a
field name just below) and was likely caused by confusion when switching
between defining fields using similar type macros and defining the type
itself.

Reviewed by:imp
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D30525

(cherry picked from commit 5e912f5fec025766521f535d1237330ede7f18e2)
---
 sys/dev/aic7xxx/aicasm/aicasm_gram.y   | 2 +-
 sys/dev/aic7xxx/aicasm/aicasm_symbol.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sys/dev/aic7xxx/aicasm/aicasm_gram.y 
b/sys/dev/aic7xxx/aicasm/aicasm_gram.y
index c479c8fdf2db..d32793f4c12b 100644
--- a/sys/dev/aic7xxx/aicasm/aicasm_gram.y
+++ b/sys/dev/aic7xxx/aicasm/aicasm_gram.y
@@ -59,7 +59,7 @@
 #include "aicasm_symbol.h"
 #include "aicasm_insformat.h"
 
-int yylineno;
+extern int yylineno;
 char *yyfilename;
 char stock_prefix[] = "aic_";
 char *prefix = stock_prefix;
diff --git a/sys/dev/aic7xxx/aicasm/aicasm_symbol.h 
b/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
index 616dfd28fdeb..a15fa12176d1 100644
--- a/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
+++ b/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
@@ -110,7 +110,7 @@ struct macro_arg {
regex_t arg_regex;
char   *replacement_text;
 };
-STAILQ_HEAD(macro_arg_list, macro_arg) args;
+STAILQ_HEAD(macro_arg_list, macro_arg);
 
 struct macro_info {
struct macro_arg_list args;
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: b305e1dfbf69 - stable/11 - aic7xxx: Fix re-building firmware with -fno-common

2021-06-03 Thread Jessica Clarke
The branch stable/11 has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=b305e1dfbf695d9082661cdb9cae830cdc592b32

commit b305e1dfbf695d9082661cdb9cae830cdc592b32
Author: Jessica Clarke 
AuthorDate: 2021-05-28 18:07:17 +
Commit: Jessica Clarke 
CommitDate: 2021-06-04 00:30:10 +

aic7xxx: Fix re-building firmware with -fno-common

The generated C output for aicasm_scan.l defines yylineno already, so
references to it from other files should use an extern declaration.

The STAILQ_HEAD use in aicasm_symbol.h also provided an identifier,
causing it to both define the struct type and define a variable of that
struct type, causing any C file including the header to define the same
variable. This variable is not used (and confusingly clashes with a
field name just below) and was likely caused by confusion when switching
between defining fields using similar type macros and defining the type
itself.

Reviewed by:imp
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D30525

(cherry picked from commit 5e912f5fec025766521f535d1237330ede7f18e2)
---
 sys/dev/aic7xxx/aicasm/aicasm_gram.y   | 2 +-
 sys/dev/aic7xxx/aicasm/aicasm_symbol.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sys/dev/aic7xxx/aicasm/aicasm_gram.y 
b/sys/dev/aic7xxx/aicasm/aicasm_gram.y
index 87fe1a25bf0a..746eb29d84db 100644
--- a/sys/dev/aic7xxx/aicasm/aicasm_gram.y
+++ b/sys/dev/aic7xxx/aicasm/aicasm_gram.y
@@ -57,7 +57,7 @@
 #include "aicasm_symbol.h"
 #include "aicasm_insformat.h"
 
-int yylineno;
+extern int yylineno;
 char *yyfilename;
 char stock_prefix[] = "aic_";
 char *prefix = stock_prefix;
diff --git a/sys/dev/aic7xxx/aicasm/aicasm_symbol.h 
b/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
index 3242152c943b..ec88d494cb6f 100644
--- a/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
+++ b/sys/dev/aic7xxx/aicasm/aicasm_symbol.h
@@ -108,7 +108,7 @@ struct macro_arg {
regex_t arg_regex;
char   *replacement_text;
 };
-STAILQ_HEAD(macro_arg_list, macro_arg) args;
+STAILQ_HEAD(macro_arg_list, macro_arg);
 
 struct macro_info {
struct macro_arg_list args;
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 0f8dab45404f - main - linux(4): Fix timeout parameter of rt_sigtimedwait syscall, which is timespec not a timeval.

2021-06-06 Thread Jessica Clarke
On 6 Jun 2021, at 15:40, Dmitry Chagin  wrote:
> 
> The branch main has been updated by dchagin:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=0f8dab45404f347752470579feccc6d2739b9570
> 
> commit 0f8dab45404f347752470579feccc6d2739b9570
> Author: Dmitry Chagin 
> AuthorDate: 2021-06-07 02:35:35 +
> Commit: Dmitry Chagin 
> CommitDate: 2021-06-07 02:35:35 +

Please fix your system clock.

Jess

___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: de295884c4ef - main - tip: Cast via intptr_t not long when casting between pointer and int

2021-06-08 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=de295884c4efd9a126dfdd8d98247de345d1f468

commit de295884c4efd9a126dfdd8d98247de345d1f468
Author: Jessica Clarke 
AuthorDate: 2021-06-08 17:30:59 +
Commit: Jessica Clarke 
CommitDate: 2021-06-08 17:30:59 +

tip: Cast via intptr_t not long when casting between pointer and int

Whilst all FreeBSD architectures have the same representation for
intptr_t and long (even if the former is int on ILP32 architectures),
this is more general and correct, and on CHERI they are not the same so
warnings are generated by default for integer-to-pointer casts that
aren't via (u)intptr_t.

Reviewed by:imp, kib
Obtained from:  CheriBSD
Differential Revision:  https://reviews.freebsd.org/D30696
---
 usr.bin/tip/tip/tip.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/usr.bin/tip/tip/tip.h b/usr.bin/tip/tip/tip.h
index ab6b2c4cd9a0..6bf94521cdfd 100644
--- a/usr.bin/tip/tip/tip.h
+++ b/usr.bin/tip/tip/tip.h
@@ -153,16 +153,16 @@ typedef
  */
 
 #define value(v)   vtable[v].v_value
-#define lvalue(v)  (long)vtable[v].v_value
+#define lvalue(v)  (long)(intptr_t)vtable[v].v_value
 
-#definenumber(v)   ((long)(v))
-#defineboolean(v)  ((short)(long)(v))
-#definecharacter(v)((char)(long)(v))
-#defineaddress(v)  ((long *)(v))
+#definenumber(v)   ((long)(intptr_t)(v))
+#defineboolean(v)  ((short)(intptr_t)(v))
+#definecharacter(v)((char)(intptr_t)(v))
+#defineaddress(v)  ((long *)(v))
 
-#definesetnumber(v,n)  do { (v) = (char *)(long)(n); } while 
(0)
-#definesetboolean(v,n) do { (v) = (char *)(long)(n); } while 
(0)
-#definesetcharacter(v,n)   do { (v) = (char *)(long)(n); } while 
(0)
+#definesetnumber(v,n)  do { (v) = (char *)(intptr_t)(n); } 
while (0)
+#definesetboolean(v,n) do { (v) = (char *)(intptr_t)(n); } 
while (0)
+#definesetcharacter(v,n)   do { (v) = (char *)(intptr_t)(n); } 
while (0)
 #definesetaddress(v,n) do { (v) = (char *)(n); } while (0)
 
 /*
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


git: 6d2648bcaba9 - main - tip: Fix pointer-vs-integer confusion

2021-06-08 Thread Jessica Clarke
The branch main has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=6d2648bcaba9b14e2f5c76680f3e7608e1f125f4

commit 6d2648bcaba9b14e2f5c76680f3e7608e1f125f4
Author: Jessica Clarke 
AuthorDate: 2021-06-08 17:30:59 +
Commit: Jessica Clarke 
CommitDate: 2021-06-08 17:30:59 +

tip: Fix pointer-vs-integer confusion

Currently IREMOTE assumes that every value is (initially) a pointer to a
long. This is true for NUMBERs, but false for STRINGs, which are instead
pointers to pointers, though on ILP32 and LP64 systems these happen to
have the same representation, but this is still a strict aliasing
violation, and of course breaks on systems where the representations are
not the same, such as CHERI. We do not currently have any BOOLs (short,
curiously) or CHARs used with IREMOTE, though the code should not be
relying on that.

This removes the unused setaddress macro, and the now-unused address
macro due to the above issue.

Reviewed by:imp, kib
Obtained from:  CheriBSD
Differential Revision:  https://reviews.freebsd.org/D30697
---
 usr.bin/tip/tip/tip.h   |  2 --
 usr.bin/tip/tip/value.c | 18 --
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/usr.bin/tip/tip/tip.h b/usr.bin/tip/tip/tip.h
index 6bf94521cdfd..298b08cb6692 100644
--- a/usr.bin/tip/tip/tip.h
+++ b/usr.bin/tip/tip/tip.h
@@ -158,12 +158,10 @@ typedef
 #definenumber(v)   ((long)(intptr_t)(v))
 #defineboolean(v)  ((short)(intptr_t)(v))
 #definecharacter(v)((char)(intptr_t)(v))
-#defineaddress(v)  ((long *)(v))
 
 #definesetnumber(v,n)  do { (v) = (char *)(intptr_t)(n); } 
while (0)
 #definesetboolean(v,n) do { (v) = (char *)(intptr_t)(n); } 
while (0)
 #definesetcharacter(v,n)   do { (v) = (char *)(intptr_t)(n); } 
while (0)
-#definesetaddress(v,n) do { (v) = (char *)(n); } while (0)
 
 /*
  * Escape command table definitions --
diff --git a/usr.bin/tip/tip/value.c b/usr.bin/tip/tip/value.c
index a4776b80d35d..9cf1052d3ea2 100644
--- a/usr.bin/tip/tip/value.c
+++ b/usr.bin/tip/tip/value.c
@@ -69,8 +69,22 @@ vinit(void)
if (p->v_type&ENVIRON)
if ((cp = getenv(p->v_name)))
p->v_value = cp;
-   if (p->v_type&IREMOTE)
-   setnumber(p->v_value, *address(p->v_value));
+   if (p->v_type&IREMOTE) {
+   switch (p->v_type&TMASK) {
+   case STRING:
+   p->v_value = *(char **)p->v_value;
+   break;
+   case NUMBER:
+   setnumber(p->v_value, *(long *)p->v_value);
+   break;
+   case BOOL:
+   setboolean(p->v_value, *(short *)p->v_value);
+   break;
+   case CHAR:
+   setcharacter(p->v_value, *(char *)p->v_value);
+   break;
+   }
+   }
}
/*
 * Read the .tiprc file in the HOME directory
___
dev-commits-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"


Re: git: 3fe1f21fb364 - main - ctf: Avoid passing a caddr_t to roundup2()

2022-03-07 Thread Jessica Clarke
On 7 Mar 2022, at 19:09, Mark Johnston  wrote:
> 
> On Mon, Mar 07, 2022 at 11:04:51AM -0800, John Baldwin wrote:
>> On 3/7/22 8:21 AM, Mark Johnston wrote:
>>> The branch main has been updated by markj:
>>> 
>>> URL: 
>>> https://cgit.FreeBSD.org/src/commit/?id=3fe1f21fb364e38f2bf7e7100dad59b067b27080
>>> 
>>> commit 3fe1f21fb364e38f2bf7e7100dad59b067b27080
>>> Author: Mark Johnston 
>>> AuthorDate: 2022-03-07 16:18:40 +
>>> Commit: Mark Johnston 
>>> CommitDate: 2022-03-07 16:20:57 +
>>> 
>>> ctf: Avoid passing a caddr_t to roundup2()
>>> 
>>> For some reason I can't reproduce this locally, but Jenkins complains.
>>> 
>>> Reported by:Jenkins
>>> Fixes:  bdf290cd3e1a ("ctf: Add v3 support to CTF tools, 
>>> ctf{convert,dump,merge}")
>> 
>> Odd, do you have a copy of the warning/error you got (and which compiler and 
>> arch?)
> 
> /usr/src/cddl/contrib/opensolaris/tools/ctf/cvt/ctf.c:1336:11: error: invalid 
> operands to binary expression ('caddr_t' (aka 'char *') and 'int')
>dptr = roundup2(dptr, 4);
>   ^
> /usr/include/sys/param.h:310:38: note: expanded from macro 'roundup2'
> #define roundup2(x, y)  (((x)+((y)-1))&(~((y)-1))) /* if y is powers of two */
> ~^~~
> 
> I'm not sure which compiler was in use.  All platforms failed.
> 
> I later tried building world in a 13.0-RELEASE amd64 jail, and that
> reproduced the failure.  So maybe the version of LLVM shipped there
> (11.0) is more picky?

8fa6abb6f4f6 ("Expose clang's alignment builtins and use them for
roundup2/rounddown2”) is in main and MFC’ed stable/13 but not
releng/13.0 so any native tool builds on FreeBSD versions prior to that
need the cast to work. Linux and macOS builds work because we always
use the in-tree compatibility headers for native tools, it’s just older
FreeBSD hosts, and world itself is of course always built against the
in-tree headers rather than the host’s, regardless of OS.

Jess




git: e14f57ffa6c9 - stable/13 - libpmc: Allow specifying explicit EVENT_xxH events on armv7 and arm64

2022-03-09 Thread Jessica Clarke
The branch stable/13 has been updated by jrtc27:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=e14f57ffa6c9d628b191af0c2b5425c223f47ef3

commit e14f57ffa6c9d628b191af0c2b5425c223f47ef3
Author: Jessica Clarke 
AuthorDate: 2022-02-15 16:10:34 +
Commit: Jessica Clarke 
CommitDate: 2022-03-09 21:04:10 +

libpmc: Allow specifying explicit EVENT_xxH events on armv7 and arm64

This is useful for processors where we don't have an event table; in
those cases we default to a Cortex A8 (armv7) or Cortex A53 (arm64) in
order to attempt to provide something useful, but you're then limited to
the counters in those tables, some of which may also not be implemented
(e.g. LD/ST_RETIRED are no longer implemented in more recent cores,
replaced by LD/ST_SPEC).

Adding the raw EVENT_xxH event lists to each table ensures that you can
always request the exact events you want, regardless of what has been
detected or is known.

Reviewed by:mhorne
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D33805

(cherry picked from commit 9f22e0959b1e2e3c9450f8b495d2c0c86699eb18)
---
 lib/libpmc/libpmc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/libpmc/libpmc.c b/lib/libpmc/libpmc.c
index 78fde0ed1f2c..d36648ee6b89 100644
--- a/lib/libpmc/libpmc.c
+++ b/lib/libpmc/libpmc.c
@@ -152,29 +152,39 @@ static struct pmc_event_descr 
soft_event_table[PMC_EV_DYN_COUNT];
 #undef __PMC_EV_ALIAS
 #define__PMC_EV_ALIAS(N,CODE)  { N, PMC_EV_##CODE },
 
+/*
+ * TODO: Factor out the __PMC_EV_ARMV7/8 list into a single separate table
+ * rather than duplicating for each core.
+ */
+
 static const struct pmc_event_descr cortex_a8_event_table[] = 
 {
__PMC_EV_ALIAS_ARMV7_CORTEX_A8()
+   __PMC_EV_ARMV7()
 };
 
 static const struct pmc_event_descr cortex_a9_event_table[] = 
 {
__PMC_EV_ALIAS_ARMV7_CORTEX_A9()
+   __PMC_EV_ARMV7()
 };
 
 static const struct pmc_event_descr cortex_a53_event_table[] = 
 {
__PMC_EV_ALIAS_ARMV8_CORTEX_A53()
+   __PMC_EV_ARMV8()
 };
 
 static const struct pmc_event_descr cortex_a57_event_table[] = 
 {
__PMC_EV_ALIAS_ARMV8_CORTEX_A57()
+   __PMC_EV_ARMV8()
 };
 
 static const struct pmc_event_descr cortex_a76_event_table[] =
 {
__PMC_EV_ALIAS_ARMV8_CORTEX_A76()
+   __PMC_EV_ARMV8()
 };
 
 static const struct pmc_event_descr tsc_event_table[] =



Re: git: 0e5c72c3cc54 - main - bsdinstall time: Replace dialog with bsddialog

2022-03-23 Thread Jessica Clarke
On 23 Mar 2022, at 15:57, Alfonso S. Siciliano  wrote:
> 
> The branch main has been updated by asiciliano:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=0e5c72c3cc5471dfa8cb42b018d623b1ef15dbe8
> 
> commit 0e5c72c3cc5471dfa8cb42b018d623b1ef15dbe8
> Author: Alfonso S. Siciliano 
> AuthorDate: 2022-03-23 15:52:39 +
> Commit: Alfonso S. Siciliano 
> CommitDate: 2022-03-23 15:56:37 +
> 
>bsdinstall time: Replace dialog with bsddialog
> 
>Replace (LGPL) dialog utility with (BSD-2-Clause) bsddialog utility,
>'dialog --calendar' is replaced by 'bsddialog --datebox' with same
>features but different User Interface.

Different in what way?..

>Approved by:bapt (mentor)
>Differential Revision:  https://reviews.freebsd.org/D34583
> ---
> usr.sbin/bsdinstall/scripts/time | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/usr.sbin/bsdinstall/scripts/time 
> b/usr.sbin/bsdinstall/scripts/time
> index cccd5999a035..5db4b48f7531 100755
> --- a/usr.sbin/bsdinstall/scripts/time
> +++ b/usr.sbin/bsdinstall/scripts/time
> @@ -36,23 +36,23 @@ export TZ
> 
> # Set date
> exec 3>&1
> -DATE=$(dialog --backtitle 'FreeBSD Installer' \
> - --title 'Time & Date' \
> +DATE=$(bsddialog --backtitle 'FreeBSD Installer' \
> + --title ' Date ' \

Why do these both have spaces around them?

Jess

>   --ok-label 'Set Date' \
>   --cancel-label 'Skip' \
> - --defaultno \
> + --default-no \
>   --date-format '%Y%m%d%H%M.%S' \
> - --calendar '' 0 40 \
> + --datebox '' 0 40 \
> 2>&1 1>&3) && date $DATE
> exec 3>&-
> 
> # Set time
> exec 3>&1
> -TIME=$(dialog --backtitle 'FreeBSD Installer' \
> - --title 'Time & Date' \
> +TIME=$(bsddialog --backtitle 'FreeBSD Installer' \
> + --title ' Time ' \
>   --ok-label 'Set Time' \
>   --cancel-label 'Skip' \
> - --defaultno \
> + --default-no \
>   --time-format '%H%M.%S' \
>   --timebox '' 0 40 \
> 2>&1 1>&3) && date $TIME



  1   2   3   4   5   6   7   8   9   10   >