With clang 15, the following -Werror warning is produced:

    sys/kern/subr_devmap.c:87:19: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
    devmap_print_table()
                      ^
                       void

This is because devmap_print_table() and devmap_lastaddr() are declared
with a (void) argument list, but defined with an empty argument list.
Make the definition match the declaration.

Sponsored by:	The FreeBSD Foundation

cgit

With clang 15, the following -Werror warning is produced:

    sys/dev/ofw/openfirm.c:826:9: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
    OF_enter()
            ^
             void

This is because OF_enter() and OF_exit are declared with a (void)
argument list, but defined with an empty argument list. Make the
definition match the declaration.

Sponsored by:	The FreeBSD Foundation

cgit

With clang 15, the following -Werror warning is produced:

    sys/dev/hwpmc/hwpmc_arm64.c:530:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
    pmc_arm64_initialize()
                        ^
                         void

This is because many of the functions are declared with a (void)
argument list, but defined with an empty argument list. Make the
definition match the declaration.

Sponsored by:	The FreeBSD Foundation

cgit

This used to trigger panics, so try to reproduce it.
Create an if_ovpn interface, set a new peer on it with a TCP fd (as
opposed to the expected UDP) and ensure that this is rejected.

Sponsored by:	Rubicon Communications, LLC ("Netgate")

cgit

We must ensure that the fd provided by userspace is really for a UDP
socket. If it's not we'll panic in udp_set_kernel_tunneling().

Reported by:	Gert Doering <gert@greenie.muc.de>
Sponsored by:	Rubicon Communications, LLC ("Netgate")

cgit

cgit

cgit

Partially from https://reviews.freebsd.org/D36027

Submitted by:	sos

cgit

The BIOS method of booting imposes an absolute limit of 640k for the
size of the program being run due to btx. In practice, this means that
programs larger than about 500kiB will fail in odd ways as the stack /
heap will overflow.

Pick 510,000 as the cutoff line semi-arbitrarily. loader_lua is now
almost too big and we want to break the build when it crosses this
threshold. In my experience, below 500,000 always works, above 520,000
always seems to fail with things getting bad somewhere between 512,000
to 515,000. 510,000 is as close to the line as I think we can go, though
experience may dictate we need to lower this in the future.

This is at-best a stop-breakage until we have a better way to subset the
boot loader for BIOS booting to allow better, more fined-tuned
/boot/loaders for the many different environments they have to run
in. This likely means we'll have a graphical loader than understands a
few filesystmes for installation, and a non-graphical loader that
understands the most filesystems possible for everything else in the
future. Our build infrastructure needs some work before we can do that,
however.

At this late date, it likely isn't worth the efforts to move parts of
the loader into high memory. There's a number of assumptions about where
the stack is, where buffers reside, etc that are fulfilled when it lives
in the first 640k that would need bounce buffers and/or other counter
measures if we were to split it up. All BIOS calls are done in 16-bit
mode with SEG:OFF addresses, requiring them to be in the first 640k of
RAM. And nearly all machines in the last decade can boot with UEFI
(though there's some exceptions, so it isn't worth killing outright
yet).

Sponsored by:		Netflix
Reviewed by:		kevans
Differential Revision:	https://reviews.freebsd.org/D36129

cgit

The first level boot blocks have understood how to load ELF code since
1999. Switch /boot/loader and /boot/pxeldr over to being ELF format so
that in-tree tools can examine them more closely. In addition, one
could, in theory, now have a 'lo-mem' and a 'hi-mem' segment (though a
lot of work would need to be done with bounce buffers, btx, code segment
marking, etc for an arrangement like that to work).

As far as I can tell, this is the last a.out binary in the tree. There
are several raw binaries left, but everything else is ELF.

Reviewed by:		emaste, kevans
Sponsored by:		Netflix
Differential Revision:	https://reviews.freebsd.org/D36130

cgit

cgit