Page MenuHomeFreeBSD

stand libsa: Restore include path to LDRSRC for disk.h for filesystems.
ClosedPublic

Authored by jhb on Jul 19 2022, 7:44 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Oct 22, 7:50 AM
Unknown Object (File)
Sat, Oct 19, 2:59 PM
Unknown Object (File)
Sep 21 2024, 7:12 AM
Unknown Object (File)
Sep 20 2024, 5:14 PM
Unknown Object (File)
Sep 19 2024, 9:06 PM
Unknown Object (File)
Sep 17 2024, 3:33 AM
Unknown Object (File)
Sep 17 2024, 1:38 AM
Unknown Object (File)
Sep 15 2024, 8:53 AM
Subscribers

Details

Summary

This fixes the build with MK_LOADER_ZFS=no.

Obtained from: CheriBSD
Fixes: 84bf2bbbecc3 stand: constrain zlib/gzip CFLAGS better
Sponsored by: DARPA

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jhb requested review of this revision.Jul 19 2022, 7:44 PM

this is incomplete.
MK_LOADER_ZFS=no
should *NOT* add LDRSRC to all CFLAGS. That must be fixed as well.

Also, this doesn't update the universe test script to include building w/o ZFS. If not there, it's not tested and will break. I didn't even know we actually supported turning this off.

Also also, nothing in libsa should need stuff from common, so this shows bugs in these files.

So this may correct the build, but there's a lot of technical debt it papers over.

diff --git a/stand/defs.mk b/stand/defs.mk
index e9c97f7720ab..3d6ad9c7997f 100644
--- a/stand/defs.mk
+++ b/stand/defs.mk
@@ -85,6 +85,8 @@ CFLAGS+=      -I${BOOTOBJ}/libsa
 .endif
 CFLAGS+=       -I${SASRC} -D_STANDALONE
 CFLAGS+=       -I${SYSDIR}
+# XXX HACK UNTIL ISSUES FIXED this should not be global
+CFLAGS+=       -I${LDRSRC}
 # Spike the floating point interfaces
 CFLAGS+=       -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface
 .if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64"

might be a better kludge until I can get this sorted out for this and the geli stuff. Can you see if this fixes your use cases and commit it instead? I've got limited availability til Sunday and this should be fixed before then (I won't be able to adequately test til then).

Or maybe something similar in libsa/Makefile...

I think I need to do a more extensive cleanup in this area.

A lot of these seem to be related to the mount code formatting the device and searching the mount list...
So that will need to be reworked to fix the layering violation...
Most of the code looks to be inlined versions of stuff that could be made common and abstract it to fit better with the filesystem support.

In D35860#814283, @imp wrote:

this is incomplete.
MK_LOADER_ZFS=no
should *NOT* add LDRSRC to all CFLAGS. That must be fixed as well.

Uh, the problem is that MK_LOADER_ZFS=yes _does_ add it to all CFLAGS. These changes at least keep it more targeted vs adding it to global CFLAGS.

In CheriBSD we don't enable ZFS currently so when merging your changes this week I had to apply these band-aids to get a tree that built at all downstream, and it really seems odd that we depend on a ZFS-specific global append to CFLAGS to build other non-ZFS files.

In D35860#814480, @jhb wrote:
In D35860#814283, @imp wrote:

this is incomplete.
MK_LOADER_ZFS=no
should *NOT* add LDRSRC to all CFLAGS. That must be fixed as well.

Uh, the problem is that MK_LOADER_ZFS=yes _does_ add it to all CFLAGS. These changes at least keep it more targeted vs adding it to global CFLAGS.

That's one of the problems I highlighted, along with the lack of MK_LOADER_ZFS=no in the universe tests.

In CheriBSD we don't enable ZFS currently so when merging your changes this week I had to apply these band-aids to get a tree that built at all downstream, and it really seems odd that we depend on a ZFS-specific global append to CFLAGS to build other non-ZFS files.

Yea, i'm sorry for the breakage. I need to audit all the options so I can build them all on/off and a few combinations.

And since I'm out of pocket for a few days, I'm approving this and the other. I've stated my preference, but these two changes are also fine.

This revision is now accepted and ready to land.Jul 20 2022, 10:42 PM

Since I originally objected and delayed this fix, I've pushed this in with John's name on it. I hope this isn't stepping on any toes. Any problems with this are likely my fault, not John's.