User Details
- User Since
- Nov 20 2015, 9:23 AM (458 w, 1 d)
Jan 16 2024
Jan 14 2024
Sep 26 2023
Aug 16 2023
Jul 19 2023
Jun 28 2023
D40787 applied the quirks for {"coreboot", "Acer", "Peppy"}, but this change does not...?
I don't have any particular context for this issue, but the description makes sense, and the code change implements it.
May 5 2023
Apr 28 2023
Apr 27 2023
Apr 26 2023
Reformat copyright, per imp@'s request.
Apr 25 2023
Describe new fields in jedec_dimm.4
Update the date for the manpage.
Apr 24 2023
Apr 20 2023
Apr 10 2023
Mar 21 2023
Maybe add an entry for groupmember() to ucred.9, along with other (struct ucred)-related functions? crsetgroups() is there, for example.
Mar 20 2023
Mar 18 2023
Mar 16 2023
I have been wondering about MPASS() forever! :-)
Mar 15 2023
Mar 14 2023
I would just have a single comment for the new functions: The target is verified, so disallow replacement.
Mar 6 2023
As discussed in email, if_foreach_sleep() sounds like the loop itself inserts a delay. I suggest changing it to if_foreach_sleepable(), which more accurately conveys that it can sleep (or use callbacks that can sleep), not that that it does sleep.
Mar 4 2023
Feb 28 2023
Jan 31 2023
The libc default is 1KB; 64KB should help significantly without excessive overhead.
Nov 18 2022
Oct 28 2022
Oct 3 2022
.Sh NOTE ZVOLs are discouraged for use as swap devices, because ZFS needs to allocate memory in order to write, which may not be possible while the system is under memory pressure. In other words, ZFS needs memory to make memory available. ZFS swap files are discouraged for the same reason.
Sep 15 2022
Is the problem when the year won't fit into an int, or specifically when it won't fit into a 32-bit int?
Sep 5 2022
I have reworded the proposed diff for better readability in English; please consider adopting any or all of these changes:
.Ss Staging Slop The kernel needs to allocate memory during very early bootstrap, when creating kernel page tables and other data structures needed for initial operations. Because the kernel cannot even parse the firmware tables describing available memory without allocating, this makes bootstrapping problematic. To solve this issue, the kernel assumes that some memory after the staging area .Po where the kernel itself, together with modules and metadata, as loaded by .Nm , resides .Pc is available for use, without causing corruption of any firmware data. .Pp It is up to the loader to ensure that the staging area is larger than just the loaded kernel, modules, and metadata, by an extra .Dq slop amount. By default, amd64 reserves 8MB. The .Ic staging_slop command allows for tuning the slop size. It takes a single argument, the size of the slop in bytes. .Ss amd64 Nocopy BIOS loaders on i386 and amd64 put the staging area starting at the physical address .Ad 2M , then enables paging with identical mapping for the low .Ad 1G . The initial port of .Nm followed the same scheme for handing control to the kernel, since it avoided modifications for the loader/kernel hand-off protocol, and for the kernel page table bootstrap. .Pp This approach is incompatible with the UEFI specification, and as a practical matter, caused troubles on many boards, because UEFI firmware is free to use any memory for its own needs. Applications like .Nm must only use memory explicitly allocated using boot interfaces. The original way also potentially destroyed UEFI runtime interfaces data. .Pp Eventually, .Nm and the kernel were improved to avoid this problem. For backward bug-compatibility, and to allow booting older kernels with newer .Nm , this .Sq nocopy behaviour can be controlled by the loader .Ic copy_staging command. It takes a single argument, which can be one of .Bl -tag -width disable .It Ar disable Force-disable copying staging area to .Ad 2M . .It Ar enable Force-enable copying staging area to .Ad 2M . .It Ar auto Selects the behaviour based on the kernel's capability of boostraping from non-2M physical base. The kernel reports this capability by exporting the symbol .Va kernphys . .El .Pp Arm64 loaders have operated in the .Sq nocopy mode from their inception, so there is no .Ic copy_staging command on that platform. .Ss amd64 Faults Because it executes in x86 protected mode, the amd64 version of .Nm is susceptible to CPU faults due to programmer mistakes and memory corruption. To make debugging such faults easier, amd64 .Nm can provide detailed reporting of the CPU state at the time of the fault. .Pp The .Ic grab_faults command installs a handler for faults directly in the IDT, avoiding the use of the UEFI debugging interface .Fn EFI_DEBUG_SUPPORT_PROTOCOL.RegisterExceptionCallback . That interface is left available for advanced debuggers in the UEFI environment. The .Ic ungrab_faults command tries to deinstall the fault handler, returning TSS and IDT CPU tables to their pre-installation state. The .Ic fault command produces a fault in the .Nm environment for testing purposes, by executing the .Ic ud2 processor instruction.
Sep 1 2022
Aug 29 2022
Aug 26 2022
Aug 23 2022
Aug 22 2022
Aug 5 2022
Given that we h ave a number of options in ports, why? What would dhcpd in base provide us that one of the alternatives in ports cannot?
Jul 28 2022
Based on my previous comments, I suggest something like this for dv_type:
.It dv_type Type of device. The supported types are: .Bl -tag -width "DEVT_NONE" .It DEVT_NONE .It DEVT_DISK .It DEVT_NET .It DEVT_CD .It DEVT_ZFS .It DEVT_FD .El Each type may have its own associated (struct type_devdesc), which has the generic (struct devdesc) as its first member.
(The markup might need a little tweaking, particularly the references to the structures, but that should be in the right ballpark.)
Jul 27 2022
Jul 26 2022
I would suggest clarifying "appropriate for the situation".
Jul 25 2022
Jul 21 2022
Jul 19 2022
FWIW, I'd switch to printf '%s' "$ROOTPASS" on general principles, to avoid the possibility of silliness.
Jul 18 2022
Jul 17 2022
Jul 16 2022
LGTM.
Jul 13 2022
LGTM.
Jul 12 2022
I implemented something similar to strverscmp() several years back, but in a much simpler (though potentially slower?) way, by leveraging strtol():
int strnumcmp( const char *s1, const char *s2) { unsigned int n1 = 0; unsigned int n2 = 0;
Jul 11 2022
May 27 2022
May 6 2022
Nice! (How did I not know that kern.msgbuf_show_timestamp was a thing?!?)