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>