Since there was no agreement whether the author's email address should be updated for a newer one, I am going to clone this one.

There is a typo in the commit message: libbbhyve.

There is a typo in the commit message: libbbhyve.

In D54606#1248653, @jrm wrote:

I think the feeling of being ignored is fairly common in the project. There is just more work to be done than time to do it all, and people often expend their energy on things that interest them.

Address style(9) fixes

Apply style(9) fixes

don't fiddle with SUNPATHLEN

In D54606#1248645, @jrm wrote:

@michaelo, I believe I've addressed all your concerns, and I've performed some light testing with manually created logs. Are you able and willing to do any testing with your real logs for the three scripts?

In D54606#1247636, @jrm wrote:

Michael, I took another look at your review, and it dawned on me that we don't need to know which timestamp format is in use. We only need patterns that match either format. Rather than trying to explain things in the other review or take it over, I thought I would first create a separate review for you to consider.
I haven't thoroughly tested this version because I don't have adequate logs.

What do you think?

In D54361#1247638, @jrm wrote:

Michael, take a look at https://reviews.freebsd.org/D54606, which might be a cleaner approach.

Maybe you should check these as well:

$ grep -r --include=Makefile ar= .
./astro/gpsd/Makefile:GEOSTAR_MAKE_ARGS_OFF=            geostar=no
./audio/cardinal/Makefile:BINARY_ALIAS= gcc-ar=ar \
./databases/leofs/Makefile:     leo-project/bear=0.8.2-for-leofs:bear \
./devel/electron37/Makefile:                    ar=${LOCALBASE}/bin/llvm-ar${LLVM_DEFAULT} \
./devel/electron38/Makefile:                    ar=${LOCALBASE}/bin/llvm-ar${LLVM_DEFAULT} \
./devel/electron39/Makefile:                    ar=${LOCALBASE}/bin/llvm-ar${LLVM_DEFAULT} \
./editors/libreoffice/Makefile:                 --with-commons-codec-jar=${JAVAJARDIR}/commons-codec.jar \
./editors/libreoffice/Makefile:                 --with-commons-httpclient-jar=${JAVAJARDIR}/commons-httpclient.jar \
./editors/libreoffice/Makefile:                 --with-commons-lang-jar=${JAVAJARDIR}/commons-lang3.jar \
./editors/libreoffice/Makefile:                 --with-commons-logging-jar=${JAVAJARDIR}/commons-logging.jar \
./editors/libreoffice/Makefile:         --with-external-tar=${DISTDIR}/${DIST_SUBDIR} \
./editors/openoffice-4/Makefile:        commons-codec-jar=${JAVALIBDIR}/commons-codec.jar              \
./editors/openoffice-4/Makefile:        commons-httpclient-jar=${JAVALIBDIR}/commons-httpclient.jar    \
./editors/openoffice-4/Makefile:        commons-logging-jar=${JAVALIBDIR}/commons-logging.jar
./editors/openoffice-4/Makefile:                        --with-commons-lang-jar=${JAVALIBDIR}/commons-lang.jar \
./editors/openoffice-4/Makefile:                        --with-beanshell-jar=${JAVALIBDIR}/bsh.jar     \
./editors/openoffice-4/Makefile:                        --with-lucene-core-jar=${JAVALIBDIR}/lucene-core-3.6.2.jar \
./editors/openoffice-4/Makefile:                        --with-lucene-analyzers-jar=${JAVALIBDIR}/lucene-analyzers-3.6.2.jar \
./editors/openoffice-devel/Makefile:    commons-codec-jar=${JAVALIBDIR}/commons-codec.jar              \
./editors/openoffice-devel/Makefile:    commons-httpclient-jar=${JAVALIBDIR}/commons-httpclient.jar
./editors/openoffice-devel/Makefile:CONFIGURE_ARGS+=    --with-commons-logging-jar=${JAVALIBDIR}/commons-logging.jar
./editors/openoffice-devel/Makefile:                    --with-commons-lang-jar=${JAVALIBDIR}/commons-lang3.jar \
./editors/openoffice-devel/Makefile:                    --with-beanshell-jar=${JAVALIBDIR}/bsh.jar     \
./editors/openoffice-devel/Makefile:                    --with-lucene-core-jar=${JAVALIBDIR}/lucene-core-3.6.2.jar \
./editors/openoffice-devel/Makefile:                    --with-lucene-analyzers-jar=${JAVALIBDIR}/lucene-analyzers-3.6.2.jar \
./filesystems/rar2fs/Makefile:          --with-unrar=`${MAKE} -C ${PORTSDIR}/${LIBUNRAR_PORT} -VWRKSRC` \
./graphics/frogr/Makefile:MESON_ARGS=   -Denable-header-bar=true
./graphics/libskiasharp/Makefile:               ar=${LOCALBASE}/bin/ar
./graphics/rawtherapee/Makefile:BINARY_ALIAS+=  ar=${AR} ranlib=${RANLIB}
./graphics/skia/Makefile:               ar=llvm-ar
./java/apache-commons-beanutils/Makefile:MAKE_ARGS+=    -Dcommons-collections.jar=${JAVALIBDIR}/commons-collections.jar \
./java/apache-commons-beanutils/Makefile:               -Dcommons-logging.jar=${JAVALIBDIR}/commons-logging.jar
./java/javahelp/Makefile:MAKE_ARGS=     -Djsp-jar=${TOMCAT_jsp} \
./java/javahelp/Makefile:               -Dfile.reference.jsp-api.jar=${TOMCAT_jsp} \
./java/javahelp/Makefile:               -Dservlet-jar=${TOMCAT_servlet} \
./java/javahelp/Makefile:               -Dfile.reference.servlet-api.jar=${TOMCAT_servlet} \
./java/javamail/Makefile:MAKE_ARGS+=    -Dactivation.jar=${DISTDIR}/jakarta.activation.jar
./java/sigar/Makefile:          -Djunit.jar="${JAVALIBDIR}/junit.jar" test
./lang/rust/Makefile:   @${ECHO_CMD} 'ar="${AR}"' >> ${WRKSRC}/config.toml
./lang/rust188/Makefile:        @${ECHO_CMD} 'ar="${AR}"' >> ${WRKSRC}/config.toml
./math/octave-forge-rtree/Makefile:BINARY_ALIAS=        tar=gtar
./math/polymake/Makefile:SINGULAR_CONFIGURE_ON= --with-singular=${LOCALBASE}
./misc/amanda-server/Makefile:          --with-gnutar=${LOCALBASE}/bin/gtar
./net-im/ejabberd/Makefile:CONFIGURE_ARGS+=--localstatedir=/var --libdir=${PREFIX}/${EJABBERD_LIBDIR} --with-rebar=rebar
./security/courier-authlib/Makefile:            --with-authdaemonvar=${AUTHDAEMONVAR} \
./sysutils/edk2/Makefile:               ar=${AR} \
./sysutils/edk2/Makefile:               gcc-ar=${LOCALBASE}/bin/${CC:S/gcc/&-ar/} \
./www/chromium/Makefile:                        ar=${LOCALBASE}/bin/llvm-ar${LLVM_DEFAULT} \
./www/iridium/Makefile:                 ar=${LOCALBASE}/bin/llvm-ar${LLVM_DEFAULT} \
./www/onlyoffice-documentserver/Makefile:BINARY_ALIAS+= ar=${LOCALBASE}/bin/llvm-ar${LLVM_DEFAULT} \
./www/ungoogled-chromium/Makefile:                      ar=${LOCALBASE}/bin/llvm-ar${LLVM_DEFAULT

https://github.com/rust-lang/rust/pull/26926

Can you investigate when this has been dropped?

print driver version in *_attach() function

Looking at booth drivers, mfi(4) uses mfi_attach() to print the message while mrsas(4) uses probe. I could move both to *_attach(), but cannot tell which of both is correct. Logically attach() seems right.

Merged into D54519

Unify both changes, use device_printf() in mrsas(4) as well

Drop 'FreeBSD' in version banner

In D54519#1248132, @ziaee wrote:

I think if you want to make them the same you should remove FreeBSD from both. If people search logs for FreeBSD they shouldn't get these drivers, I think.

In D54519#1248132, @ziaee wrote:

I think if you want to make them the same you should remove FreeBSD from both. If people search logs for FreeBSD they shouldn't get these drivers, I think.

I had the following objective:

• Make the string compatible with mrsas(4) since both drivers overlap
• Reflect the author of the driver back then, not now
• Keep mfi in the script because it makes the string consistent with the first point

@imp Any objections or opinions here?

@ziaee, thank you very much for the backports. This perfect now.

In D54608#1248076, @haraldei wrote:

In D54608#1247967, @michaelo wrote:

In D54608#1247947, @haraldei wrote:

In D54608#1247892, @michaelo wrote:

Where does openjdk19-19.0.2+7.1_4.${JDK_ARCH}.tar.xz come from and how is it produced?

From pkg.freebsd.org. It's the release pkg file that has been extracted, moved to the boot-jdk directory and compressed and packed with tar. The only exception is the ppc64(le) tarballs as there's no official packages of these, so they are built by pkubaj@.

It seems that the port will never be selfcontained in the ports tree, no?

The OpenJDK ports were never self contained. They either depended on the port of the previous version, or in some cases a bootstrap-jdk that was installed to the system. The main difference in this approach is that we don't rely on the previous jdk, and we don't install the bootstrap-jdk to the system.

I see, it applies the Münchhausen trilemma which is logically flawed, but we cannot change it.

No, we can only try to make the best of it. Java is needed to build the JDK, so having a presumably good package to build from is as good as it gets, I think. I plan to document the scripts I use to generate these boot-jdk tarballs, and hopefully we can automate it completely from the build system at some point. This is the first step.

How to solve this in the future with newer FreeBSD versions? If there is an so bump in base, the base package is unusable unless compat is installed or the build JDK is rebuilt?

I've been thinking about this, but don't have a good answer yet. We may need to keep bootstrap-jdks for each major FreeBSD base version as well as each supported OpenJDK. These packages are from FreeBSD 14.3 and seem to work fine on 15 as well for now. But it's definitely a thing to be aware of.

In D54608#1247947, @haraldei wrote:

In D54608#1247892, @michaelo wrote:

Where does openjdk19-19.0.2+7.1_4.${JDK_ARCH}.tar.xz come from and how is it produced?

From pkg.freebsd.org. It's the release pkg file that has been extracted, moved to the boot-jdk directory and compressed and packed with tar. The only exception is the ppc64(le) tarballs as there's no official packages of these, so they are built by pkubaj@.

It seems that the port will never be selfcontained in the ports tree, no?

The OpenJDK ports were never self contained. They either depended on the port of the previous version, or in some cases a bootstrap-jdk that was installed to the system. The main difference in this approach is that we don't rely on the previous jdk, and we don't install the bootstrap-jdk to the system.

Where does openjdk19-19.0.2+7.1_4.${JDK_ARCH}.tar.xz come from and how is it produced? It seems that the port will never be selfcontained in the ports tree, no?

@jrm, are we good now? I'd like to complete this.

@des Is this acceptable now?

In D54571#1246852, @ziaee wrote:

Also, in your last commit to stable/13, you violated two rules:

1. Commit messages are wrapped at 72 characters.

No function change, diffed the driver between CURRENT and stable/1{3,4} and they are identical, but the manpage updates have never been cherry-picked.

In D54566#1246656, @ziaee wrote:

This list is by controller, and the 2208 controller is already listed, so this would make the table inconsistent. I think we should not add it to this table.

Here is the documentation for the mrsas(4) driver.

In D54520#1246464, @ziaee wrote:

In D54520#1246460, @michaelo wrote:

In fact, mrsas(4) mentions:

HARDWARE
     The mrsas driver supports the following hardware:

     [ Thunderbolt 6Gb/s MR controller ]
     •   LSI MegaRAID SAS 9265
     •   LSI MegaRAID SAS 9266
     •   LSI MegaRAID SAS 9267
     •   LSI MegaRAID SAS 9270
     •   LSI MegaRAID SAS 9271
     •   LSI MegaRAID SAS 9272
     •   LSI MegaRAID SAS 9285
     •   LSI MegaRAID SAS 9286
     •   DELL PERC H810
     •   DELL PERC H710/P

     [ Invader/Fury 12Gb/s MR controller ]
     •   LSI MegaRAID SAS 9380
     •   LSI MegaRAID SAS 9361
     •   LSI MegaRAID SAS 9341
     •   DELL PERC H830
     •   DELL PERC H730/P
     •   DELL PERC H330

Let me evaluate this in a separate review.

No, it hasn't for a while. Please conduct development from up to date sources.

In fact, mrsas(4) mentions:

HARDWARE
     The mrsas driver supports the following hardware:

In D54520#1246442, @ziaee wrote:

If it works for both, should we list it for both?

In D54519#1246275, @ziaee wrote:

Thanks for tagging me!

I try to be careful with "FreeBSD" as a search term, I don't think it's appropriate in these driver strings. I also don't know if it matters that it's broadcom megaraid now.

Maybe imp should review this. I'm going to add emaste because he's one marked up the broadcom.

Here is the output from the server:

Screenshot from the machine with both drivers now side by side:

I think this should have happened *after* new bootstrap ports have emerged...

An alternative approach is to create a GitHub project and pull it from there...

This can be used on any client which is either AD joined or you have a DNS server which support GSS-TSIG.

Fix sort order

Should we (re)consider this for 16-CURRENT or abandon?

@fernape, would you mind to formally review and approve this as well?

Remove build file

Obey style(9)

Add needs_ipv6_brackets

@des Let's complete this one first.

Today's security message from a 16-CURRENT VM:

Checking setuid files and devices:

Spinoff: https://reviews.freebsd.org/D54412

I can confirm your observations:

root@deblndw013x10v:~/freebsd-src (main %>)
# ps -o command= -p $(pgrep syslogd)
/usr/sbin/syslogd -N -ss -O rfc5424
syslogd: syslogd.casper (syslogd)
syslogd: system.net (syslogd)
root@deblndw013x10v:~/freebsd-src (main %>)
# uname -a
FreeBSD deblndw013x10v.innomotics.net 16.0-CURRENT FreeBSD 16.0-CURRENT #1 use-iso-8601-build-n282325-56b9c752e8d6: Fri Dec  5 18:14:04 CET 2025     root@deblndw013x10v.innomotics.net:/usr/obj/root/freebsd-src/amd64.amd64/sys/GENERIC amd64

In D54411#1243438, @ziaee wrote:

I asked Claude Sonnet

This is currently prohibited afaik. It's a lot of work to check it, but I doubt that the LLM didn't hallucinate any of this as well. There is very little benefit in massaging 13 at this point.

In D54408#1243435, @ziaee wrote:

I asked Claude Sonnet

This is currently prohibited afaik.

This is for 13-STABLE only!

I asked Claude Sonnet to diff both linprocfs.5, then diff both manpages and apply the style of 15 to 14 leaving out what is in 15 only. I will create a review for 13 as well.