[Bug 257514] Can not embed ZFS into Kernel on RelEng/13.0 i386

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257514

--- Comment #1 from CrazyMihey <CrazyMihey@Ya.Ru> ---
UnFortunately, NoOne answers My Question ↑, so I dicided to Try to Fix This
Annoying Bug MySelf.
It seems, the Reason of Error just on «i386» Architecture is in Next Part of
«/usr/src/Makefile.inc1»:
#──────────────────────────────────────────────────────────────────────────────────────────────────#
# 20191009  r353340  removal of opensolaris_atomic.S (also r353381)
.if ${MACHINE} != i386
.for f in opensolaris_atomic
.for m in opensolaris zfs
        @if [ -e
"${KRNLOBJDIR}/${KERNCONF}/modules${SRCTOP}/sys/modules/${m}/.depend.${f}.o" ]
&& \
            grep -q ${f}.S
"${KRNLOBJDIR}/${KERNCONF}/modules${SRCTOP}/sys/modules/${m}/.depend.${f}.o";
then \
                echo "Removing stale dependencies for opensolaris_atomic"; \
                rm -f
${KRNLOBJDIR}/${KERNCONF}/modules${SRCTOP}/sys/modules/${m}/.depend.${f}.*; \
        fi
.endfor
.endfor
.endif
#──────────────────────────────────────────────────────────────────────────────────────────────────#
I will Try to Build a Simpliest Kernel Configuration is
«/usr/src/sys/i386/conf/Virtual_ZFS»:
#──────────────────────────────────────────────────────────────────────────────────────────────────#
include GENERIC                 # За Основу берётся Общий Файл Конфигурации
«GENERIC» для FreeBSD/AMD64.

ident   Virtual_ZFS             # Уникальное Идентификационное НаЗвание Ядра.
Должно совпадать с Именем Этого Файла.

nooptions       ZFS
options         ZFS             # ПодДержка ZettaByte File System в Ядре ОС.
options         KSTACK_PAGES=4  # Количество Страниц Памяти, ВыДеляемых для
Стэка Ядра на Каждый Процесс (Поток). Повышает Стабильность Работы ZFS на
Архитектуре i386 (x86, 32 Бит). Для Архитектуры AMD64 (x86-64, 64 Бит)
Рекомендуемое Значение: «5».
makeoptions     WITHOUT_MODULES+="crypto cryptodev aesni opensolaris zfs"      
# Если Код Менеджера Томов/Файловой Системы ZFS ЛинкуетСя в Ядро Системы, то
НеОбХодимОСть в ЗаГружаемых Модулях «/boot/kernel/opensolaris.ko» и
«/boot/kernel/zfs.ko» ОтПадает.
#──────────────────────────────────────────────────────────────────────────────────────────────────#
Now I see Two Ways to ReEnAble Building i386-Kernel with BuiltIn ZFS Support in
13.0:
1. Get the File «opensolaris_atomic.S» from any Previous Release of FreeBSD
Sources:
fetch --output="-" --verbose
"HTTPS://DownLoad.FreeBSD.Org/ftp/releases/i386/12.2-RELEASE/src.txz" | tar
--extract -f "-" --directory "/" --include
"*[Oo][Pp][Ee][Nn][Ss][Oo][Ll][Aa][Rr][Ii][Ss]_[Aa][Tt][Oo][Mm][Ii][Cc].[Ss]"
--fast-read --preserve-permissions --verbose
But It does not Compile with the following Error:
#──────────────────────────────────────────────────────────────────────────────────────────────────#
…
--- all_subdir_opensolaris ---
/usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/ccompile.h:174:13:
error: unexpected token in argument list
--- all_subdir_ossl ---
--- sha1-586.o ---
--- all_subdir_otus ---
--- device_if.h ---
--- all_subdir_opensolaris ---
typedef int bool_t;
            ^
/usr/src/sys/contrib/openzfs/include/os/freebsd/spl/sys/ccompile.h:175:13:
error: unexpected token in argument list
typedef int enum_t;
            ^
*** [opensolaris_atomic.o] Error code 1

make[4]: stopped in /usr/src/sys/modules/opensolaris
…
#──────────────────────────────────────────────────────────────────────────────────────────────────#
Does It Really Can Atomic-Operate with 128-Bit Numbers on a 32-Bit CPU without
Support of «CmpXChg16B»?
2. Completely throw out «opensolaris_atomic.S» from the i386-Sources Tree:
sed -E -i "~" "s~^([^#]*opensolaris_atomic.S.*)$~#\1~"
"/usr/src/sys/conf/files.i386"
After that, Kernel Builds SuccessFully and even Runs, but I am not Sure, that
It is a «Good Idea»:
File «opensolaris_atomic.S» looks like must Operate Much Faster, than
«/usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c», which uses
Mutexes on Every Operation.
Can SomeOne from the KnowledgEable Suggest a More Correct Solution?

-- 
You are receiving this mail because:
You are the assignee for the bug.