[RFC] SBBR Test Case Additions to FWTS

[Leif Lindholm]

On Tue, Jan 10, 2017 at 01:18:57PM -0700, Jeffrey Hugo wrote:
> >Alternatively, would it be acceptable to flip that logic?
> >/sys is definitely the preferable method to access both ACPI and
> >SMBIOS, and the only one that should be used on any ARM system.
> 
> Why do you feel /dev/mem is invalid on ARM systems?

Well, it's unsuitable on any general-purpose system (it's basically
the opposite of what an operating system is for). This is why we
implemented/extended the /sys interfaces for ACPI and SMBIOS.

But it's worse on ARM than on x86, since there is no standardised
memory map. If you want a simple way of mapping a gpio block into a
userspace process on an embedded board, it's not the end of the world,
but in a multi-user or server system it's an invitation to take the
system down from userspace.

(Yes, complete system deadlocks from running dmidecode were seen in
real life before the command was changed to not go scanning through
RAM looking for tables.)

> I notice that it is
> default y, and the ARM64 defconfig in upstream Linux does not disable it, so
> it would be enabled by default for every ARM system that didn't have some
> vendor/distro manually disable it.

*nod* It took some time to get the switch to disable it implemented to
begin with - for the longest time it was always enabled for all
architectures.

> I see CONFIG_DEVMEM is enabled on on our test builds, and it appears Ubuntu
> has it enabled as well.  I'm unfamiliar with LuvOS, but I suspect it relies
> on the default y behavior.

Indeed.

> Off the top of my head, I have no issue with flipping that logic, but I'd
> want to test it first, since I know Fan just fixed the use of /dev/mem [1],
> and I wouldn't want to see a backward slide in how our platform tests in
> FWTS.
> 
> [1] https://lists.ubuntu.com/archives/fwts-devel/2016-November/008744.html

For the above reasons, I would have preferred an "#ifdef PC" approach.
But I confess to not following this list too closely and completely
missing the patch when it went past. That said, it clearly is the
kernel's job to protect itself.

/
    Leif