Reopen at the request of submitter.

This works for us in the FreeBSD cluster. Thanks!

Let me do a quick test on the cluster ThunderX1 machine.

From the release notes and will be in the commit log:

0.o Remove the other directories from this review.

In D16164#342962, @cem wrote:

In D16164#342951, @erj wrote:

can iflib.ko be created and then the driver modules depend on that?

That would be really nice. :-P

Driver modules already can and do depend on iflib, without forcing it to be a kld object (.ko) — grep for MODULE_DEPEND(..., iflib, ...).

If the idea is pulling iflib out of the kernel just for space savings, I'm not sure that really makes sense on any platform that supports iflib drivers anyway (i.e., non-embedded).

Please do add the IFLIB option to most/all GENERICs simultaneously with this change, though.

In D16164#342938, @rgrimes wrote:

Does this not also make it so that these drivers require IFLIB, so they need to be marked as such in GENERIC/NOTES/etc and man pages?

Add riscv and mips configurations to keep ZSTDIO building for
the GENERIC target and MALTA targets (std.MALTA).

Hrm. Phabricator seems to think there's no context for your diff here. What's that all about?

I was just looking at making ZSTD a compile option via ZSTDIO here https://reviews.freebsd.org/D16007

In D16007#338923, @cem wrote:

In D16007#338919, @sbruno wrote:

Maybe I just don't see it. What's the relationship between ZFS and ZSTD?

ZFS supports compressing file data. One algorithm it can use is Zstd.

Edit: https://reviews.freebsd.org/D11124 — I guess it's not in OpenZFS nor FreeBSD yet.

In D16007#338847, @markj wrote:

Doesn't it also need to be conditional on ZFS support?

In D16007#338847, @markj wrote:

Doesn't it also need to be conditional on ZFS support?

I will compile commit this review.

Hrm ... this patch seems like abandon ware to me. Is it still relevant?

bump. @olivierd Do you intend to commit this or do you need a doc committer to finish this off?

@jtl Can you close this as it appears @mmacy committed functionally the same thing? Or is there work yet to be done here?

bump. @markj Did you want to shovel this into head?

Heh, I can accept my own revision. :-)

After building the src.conf man page, update the WITHOUT_SERVICESDB entry to
generate something that looks more sensible.

Sort by alpha as per @emaste.

Adding my "ok" pending bnxt review by @shurd

In D15211#330309, @sbruno wrote:

root@lab:/home/sbruno/bsd/fbsd_head # env | grep SRCCONF
SRCCONF=/home/sbruno/bsd/src.conf.efitest
root@lab:/home/sbruno/bsd/fbsd_head # cat ${SRCCONF}
WTTHOUT_EFI="YES"
root@lab:/home/sbruno/bsd/fbsd_head # make delete-old DESTDIR=/tftpboot/netboot
>>> Removing old files (only deletes safe to delete libs)
>>> Old files removed
>>> Removing old directories
>>> Old directories removed
To remove old libraries run 'make delete-old-libs'.
root@lab:/home/sbruno/bsd/fbsd_head # make delete-old MK_EFI=no DESTDIR=/tftpboot/netboot                                                                                                                                                    
>>> Removing old files (only deletes safe to delete libs)
remove /tftpboot/netboot/usr/sbin/efibootmgr?

In D15211#330335, @emaste wrote:

Is setting it in the environment expected to work? What about make SRCCONF=/foo/bar/baz ...?

Don't nuke *all* the efi tools if OPENSSL isn't installed. (imp)

hrm ... WITH_EFI="NO" has zero effect as well. So, I'm stumped.

Pending no further review comments, this will go in the tree on Monday, May 31. That way folks can yell at me when we all get together in Ottawa.

WITHOUT_EFI="YES" seems to do nothing.

Exclude MK_EFI things if OPENSSL is unset with some better
syntax.