loader.efi: efipart needs to use ioalign

UEFI specification 2.7A, EFI_BLOCK_IO_PROTOCOL, page 566.

The ioalign property does define the alignment of data buffer.

If the alignment is required and o

loader.efi: efipart needs to use ioalign

UEFI specification 2.7A, EFI_BLOCK_IO_PROTOCOL, page 566.

The ioalign property does define the alignment of data buffer.

If the alignment is required and our buffer is not aligned, or if
the data buffer is not multiple of Blocksize, we need to use bounce buffer
to perform the block IO. This is much like with BIOS version, except
there the INT13 needs buffer to be located in low memory.

MFS: r353501
MFC: r347195,350654-350656,351274,351630,351637,352421,352439,352443-352446,352451

Approved by: re (gjb)

show more ...

MFC r343755:

Regularize the Netflix copyright

Revert r351902 ... it didn't properly exclude rack.c changes

MFC r343755:

Regularize the Netflix copyright

MFC r351408-r351410: reduce pollution from mips machine/regnum.h

r351408:
libsa: mips: use _JB_* from machine/asm.h, remove regnum dep

This brings the libsa/mips _setjmp implementation closer to pa

MFC r351408-r351410: reduce pollution from mips machine/regnum.h

r351408:
libsa: mips: use _JB_* from machine/asm.h, remove regnum dep

This brings the libsa/mips _setjmp implementation closer to parity with the
libc version.

r351409:
mips: hide regnum definitions behind _KERNEL/_WANT_MIPS_REGNUM

machine/regnum.h ends up being included by sys/procfs.h and sys/ptrace.h via
machine/reg.h. Many of the regnum definitions are too short and too generic
to be exposing to any userland application including one of these two
headers. Moreover, these actively cause build failures in googletest
(template <typename T1 ...> expanding to template <typename 9 ...>).

Hide the definitions behind _KERNEL or _WANT_MIPS_REGNUM, and patch all of
the userland consumers to define as needed.

r351410:
libsa: mips: fix typo that had slipped into the diff on local machine

show more ...

MFC r351119, r351135-r351136, r351412: stand xtoolchain-llvm90 fixes

r351119:
stand: push LIBC_SRC up into defs.mk

Other parts of stand/ that don't use libsa will need to grab bits from libc
shortl

MFC r351119, r351135-r351136, r351412: stand xtoolchain-llvm90 fixes

r351119:
stand: push LIBC_SRC up into defs.mk

Other parts of stand/ that don't use libsa will need to grab bits from libc
shortly. Push LIBC_SRC up to defs.mk in advance of this so that they can use
it, and rename it to LIBCSRC to match the convention of the rest of the *SRC
variables in this file.

r351135:
stand: boot2: fix build with xtoolchain-llvm90

ufsread.c grows a dependency on __ashldi3 with llvm90. Grab ashldi3.c out of
compiler-rt rather than trying to link against libsa (for now).
-Wno-missing-prototypes is necessary to compile ashldi3.c standalone.

r351136:
stand: gptboot: fix build with xtoolchain-llvm90

ufsread.c grows a dependency on __ashldi3 with llvm90. For gptboot, just
start pulling in ashldi3.c ashrdi3.c lshrdi3.c into libsa for all archs as
the number of archs requiring one or more of them keeps growing. qdivrem.c
and quad.h can be trivially kicked out of libsa if we start pulling these
from compiler-rt as qdivrem was only used to implement umoddi3, divdi3,
moddi3 (also in qdivrem.c).

r351412:
stand: boot2: fix amd64-xtoolchain-gcc build

-Wno-missing-declarations is the GCC equivalent of
-Wno-missing-prototypes... this was overlooked in r351135.

show more ...

loader: support com.delphix:removing

MFC r348353: boot1.efi should also provide Calloc
MFC r350772: loader: support com.delphix:removing
MFC r350825: loader: add error check for vdev_indirect calls

loader: support com.delphix:removing

MFC r348353: boot1.efi should also provide Calloc
MFC r350772: loader: support com.delphix:removing
MFC r350825: loader: add error check for vdev_indirect calls

As prerequisite, we need Calloc in boot1 so we would not conflict with libsa.

We should support removing vdev from boot pool. Update loader zfs reader
to support com.delphix:removing.

Relnotes: yes

show more ...