The use of uint64_t for the base address was because the SMBIOS
specification [2] defines the start address as 64-bit (p24 on the
version referenced). I suppose it's conceivable that some machines have
the start address beyond the ~4GB 32-bit boundary, though none of mine
do.

You are right about the position of the FLAG_NO_SYSFS change, my silly
mistake.

The spec defines WORD, DWORD, QWORD types and with the macros in types.h
as shipped this results in pointer-alignment warnings on every
occurrence when building. Redefining them to use unintptr_t from
stdint.h needed it to be included in the main executables dmidecode,
biosdecode, etc. 

I have now changed types.h to include stdint there, and tried a clearer
more portable way to prevent the alignment warnings from happening. I
suppose we could leave this out if we are happy to accept the many
build-time warnings, because it seems x86 can tolerate it and the port
is amd64/i386 only. Updated diff attached, with 3 fewer patched files.
Tested on one amd64 machine thus far.

In an ideal world reading /dev/mem from user space would not be needed
at all. I understand from the lists that it might be prevented
altogether in future. I incorrectly said before that having a sysctl
like hw.smbios could avoid it, but that only helps if the smbios data
(3-6kB on my machines) was also exported somewhere accessible from
userland on boot. Not an area I would feel comfortable going myself
with my skill level, though.

I'll get in touch with dmidecode upstream and see if any of these
patches can be accepted by them, and keep the list informed.

Chris 

[2]
https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.1.1.pdf



On Sat, 11 Oct 2025 11:19:56 +0100
Stuart Henderson <stu@spacehopper.org> wrote:

> it may be easier to get traction if you just go with the specific
> features you want first. (consider that what you see as doc
> imorovements may be seen as adding unnecessary clutter).
> 
> other comments from the diff;
> 
> they don't use uint64_t at all. stick to their idioms. does that also
> avoid adding headers to multiple files?
> 
> setting FLAG_NO_SYSFS for openbsd is in the wrong place, it should
> orobably happen regardless of FLAQ_QUIET, just printing the extra
> message should depend on FLAG_QUIET
> 
> 
> On 2025/10/11 17:52, Chris Billington wrote:
> > I can certainly try with upstream, will report how it goes. The
> > code is Linux-centric with a nod to FreeBSD in places.
> > 
> > I tried for some time to read the entry point info through efi
> > ioctls, to try and avoid the need for a new option, but it seems
> > there is very little standardisation of efi table guids despite the
> > SMBIOS spec specifying them. My three test machines were all
> > different.
> > 
> > If there was a read-only sysctl like 'hw.smbios' added on boot
> > alongside hw.model, hw.serialno (etc) that seem to come from EFI,
> > that might be easier to implement in the area of the efi-scanning
> > code in dmidecode, which is Linux/FreeBSD only as it stands. But
> > that's beyond my skills to implement. 
> > For FreeBSD, it reads a kernel hint [1]. 
> > Parsing our dmesg buffer seems a little fragile. Then that would
> > avoid having to enable kern.allowkmem and messing with /dev/mem,
> > which is not something I am greatly happy about.
> > 
> > Chris
> > 
> > [1] https://svnweb.freebsd.org/base?view=revision&revision=307326
> > 
> > On Sat, 11 Oct 2025 10:29:23 +0100
> > Stuart Henderson <stu@spacehopper.org> wrote:
> > 
> > > these changes are bigger than we'd usually like to make in porrts,
> > > even the simple ones like adding short flags to the summary will
> > > make it harder to updste. can you see about getting them included
> > > upstream (probably via their mailing list) instead?
> > > 
> > > if they're committed upstream then I don't mind pulling the
> > > patches across before they make a new release, because then we
> > > can just remove patches again when updating.
> > > 
> > > On 2025/10/11 15:19, Chris Billington wrote:
> > > > 
> > > > Hi ports@,
> > > > 
> > > > I know you are in lock at present and it's too late for 7.8
> > > > packages, but I have made an update for sysutils/dmidecode
> > > > (based on version 3.6) that adds a new option to make it work on
> > > > legacy-free UEFI systems, plus several documentation and build
> > > > improvements. A unified diff is attached, created with cvs diff
> > > > -uNp against the OPENBSD_7_7 branch.
> > > > 
> > > > Summary of changes
> > > > 
> > > > New -m option
> > > > On OpenBSD, dmidecode scans only /dev/mem in the Legacy BIOS
> > > > area. The -m option allows scanning of a 64kB range of /dev/mem
> > > > starting from a specified base address. This is useful on
> > > > modern UEFI-only systems where the SMBIOS entry point
> > > > information is not present in the legacy BIOS area 0xF0000–
> > > > 0xFFFFF. The base address can be taken from the dmesg, e.g.:
> > > > 
> > > > $ grep SMBIOS /var/run/dmesg.boot
> > > > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xa4df8000 (36 entries)
> > > > 
> > > > On some machines, specifying a slightly lower base address may
> > > > be necessary to find the _SM3_ pointer to the real entry point.
> > > > 
> > > > Other quality-of-life changes
> > > > 
> > > > - Updated dmidecode(8) to add previously-undocumented short
> > > > options found in the source. Added the new -m option.
> > > > 
> > > > - Added a pkg/README file with notes on usage on modern EFI
> > > > systems.
> > > > 
> > > > - Compile-time warning fixes. Suppressed numerous
> > > > pointer-alignment warnings by adjusting types.h macros for
> > > > WORD, DWORD, and QWORD. Added
> > > > #include <stdint.h> to source files where missing, to support
> > > > #this.
> > > > 
> > > > - made the -no-sysfs option the default on OpenBSD.
> > > > 
> > > > Rationale
> > > > 
> > > > On many newer amd64 machines, the kernel locates SMBIOS tables
> > > > via EFI and reports them in dmesg, but there is often no legacy
> > > > BIOS entry point in low memory, so dmidecode can't find an
> > > > SMBIOS Entry Point. The -m option allows dmidecode to locate
> > > > and parse those tables directly via /dev/mem, without relying
> > > > on EFI runtime variable or system-table access. Behavior is
> > > > unchanged when -m is not used.
> > > > 
> > > > Testing
> > > > 
> > > > Panasonic CF-SZ6 (OpenBSD 7.7-release/amd64) — no legacy SMBIOS
> > > > pointer; -m successfully decodes tables at EFI address.
> > > > 
> > > > Lenovo T470 (OpenBSD 7.8-beta/amd64) — same result as above.
> > > > 
> > > > Dell OptiPlex 3060 SFF (OpenBSD 7.7/amd64) — both vanilla
> > > > dmidecode (legacy F-segment) and -m 0xE0000 work correctly.
> > > > 
> > > > Verified normal output and no regressions when run without -m,
> > > > tested the missing short option-codes.
> > > > 
> > > > i386 testing would be welcome; I do not have compatible hardware
> > > > available.
> > > > 
> > > > Diff attached: dmidecode-m-option.diff
> > > > 
> > > > Comments, feedback?
> > > > OK to commit after unlock?
> > > > -- 
> > > > Chris Billington
> > > 
> > > 
> > 
> > 
> > -- 
> > Chris Billington <emulti@disroot.org>


-- 
Chris Billington <emulti@disroot.org>

• dmidecode-m-option-2.diff (13K)