Hello Chris, On Tue, 2025-10-14 at 11:27 +0800, Chris Billington via dmidecode-devel wrote: > > The message below didn't appear in the Archives after 48 hours or so > maybe due to spam filtering, so I am re-sending after joining the list > to see if that works.
We have moderation enabled for non-members, and I've been pretty busy earlier this week. Sorry about that. I would have let your message(s) through today, but as you've re-posted already, I discarded the original messages to avoid duplicates. > On Sun, 12 Oct 2025 23:04:03 +0800 > Chris Billington <[email protected]> wrote: > > > Dear dmidecode developers, > > > > I am an OpenBSD user and have been using the OpenBSD port for > > dmidecode-3.6. On OpenBSD, with no sysfs or easy userspace access to > > EFI table listings, dmidecode falls back to scanning /dev/mem at the > > legacy bios address range from 0xF0000-0xFFFFF. > > On many modern UEFI machines, there is no SMBIOS information in this > > range, so the entry point and table information cannot be found. This > > is the case on two of three of my own amd64 machines. > > > > However, the OpenBSD EFI bootloader does scan EFI tables and the > > SMBIOS entry point, if found, appears in the system message buffer on > > boot, for example: > > ... > > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xa4df8000 (36 entries) > > ... > > > > I found that by hard-coding the memory-scan base address, dmidecode > > works normally. I then created a patch to add a command-line option > > -m/--mem-base <addr> to pass an arbitrary address to the memory-scan > > function. This may also be useful as an advanced option on > > machines that have incorrect info in efi tables. Without the -m > > option, the code behaves as before. I get the idea. On the implementation, I think you hooked at the wrong place. If you already know the address, then there's no need to perform a memory scan, instead you can read the entry point directly at the given address. This is much more like the code in address_from_efi() than the memory_scan case. That being said, taking a step back, I think this is not the best solution to your problem. A better solution would be to obtain the address from the kernel directly, so that the user doesn't have to go through the tedious steps of searching through the system message buffer for the address and building the appropriate command line, which will be different for every system. As a matter of fact, this specific issue was already solved years ago on FreeBSD and DragonFly BSD, which also do not have sysfs. There, the SMBIOS entry point address is exposed through the kernel environment. Can't OpenBSD do the same? > > While making the patch I found that some of the short-option codes > > (-S, -O...) in dmiopt.c were not in the dmidecode(8) manpage or the > > help text, so added those into the patch. These short options aren't missing from the man page, they simply do not exist, on purpose. The way getopt_long works makes it mandatory to attribute a unique identifier to long options, but this is an internal only implementation detail. I used letters for convenience, but I might as well have used arbitrary numbers. > > Another suggested patch is to make FLAG_NO_SYSFS the default on > > OpenBSD (it may also be useful to do this on other BSDs). Good idea. I wonder how much code the compiler would manage to optimize out by just hard-coding FLAG_NO_SYSFS. It might also make sense to use #ifdefs to actively strip everything related to sysfs from non-Linux builds. It would probably be cleaner, as for example we could prevent - -help from listing the --no-sysfs option at all on such systems. > > Git HEAD as of today with the patch builds and works correctly on both > > my legacy-free machines and also on the third machine with the legacy > > bios information. > > > > Compilation warnings > > > > OpenBSD uses clang as default compiler. Both before and after the > > patch, it emits -Wcast-align warnings for each use of the macros WORD, > > DWORD and QWORD defined in type.h, about 300 in total. > > > > Example: > > > > dmidecode.c:612:26: warning: cast from 'const u8 *' (aka 'const > > unsigned char *') to 'const u16 *' (aka 'const unsigned short *') > > increases required alignment from 1 to 2 [-Wcast-align] > > pr_list_item("0x%04X", WORD(p + sizeof(u16) * i)); > > ^~~~~~~~~~~~~~~~~~~~~~~~~ ./types.h:31:24: note: expanded from macro > > 'WORD' > > #define WORD(x) (u16)(*(const u16 *)(x)) > > ^~~~~~~~~~~~~~~~ > > > > Compilation succeeds, because the x86 platform is tolerant of such > > alignment issues. However, other platforms that need strict alignment > > may not build. (The port is amd64/i386 only on OpenBSD, however). This has been reported before, but this is a false positive. If you look at the code, you'll see that there is alternative (and slower) code used on hardware which is not tolerant to unaligned memory access. That being said, I agreed to rewrite this part of the code to make compilers such as clang happy. Discussion is archived here: https://lists.nongnu.org/archive/html/dmidecode-devel/2025-06/msg00019.html There were a few technical issues to clarify, which is why this hasn't been committed yet, but I can (and should) resume working on it. If you want, I can send you the patch I plan to commit so that you can test and report if it works properly on your systems. > > I made a patch for types.h that avoids these cast-alignment warnings > > by using memcpy() to ensure alignment on architectures that allow > > unaligned reads, like x86. > > > > I attach two git diffs against HEAD (12 Oct 25/ > > fa268715c0d7d8895842c6f9b92bcc1a17790000): > > option-m-docs.diff (-m and dmidecode.8) > > types-h.diff (-Wcast-align) > > > > Tested on amd64 with clang16 and gcc 11.2 > > > > Would you have any interest in adding these patches to your codebase, > > rather than OpenBSD making local changes to their port? They could be > > useful to general users on other platforms. I isolated the changes to > > types.h so they can be tested separately. If you would prefer to > > receive patches in a different format please let me know. The general rule is that I would prefer if a BSD port was not needed at all and you could simply build the upstream code without any change. This is already the case on Linux and, to the best of my knowledge, FreeBSD and DragonFly BSD. But of course the proposed changes have to be acceptable (i.e. clean fixes, not hacks). When it comes to the format of the contributions, splitting patches by modified files isn't the preferred approach. Best if to submit a separate patch for each functional change. This makes the reviewing process much smoother. Upstream commits must follow this rule anyway. Thanks, -- Jean Delvare SUSE L3 Support
