On Tue, Jan 21, 2020 at 10:29:35AM -0600, Eric W. Biederman wrote: > Jean Delvare <jdelvare@xxxxxxx> writes: > > > On Mon, 20 Jan 2020 23:55:43 +0200, Andy Shevchenko wrote: > >> On Mon, Jan 20, 2020 at 11:44 PM Jean Delvare <jdelvare@xxxxxxx> wrote: > >> > > >> > On Mon, 20 Jan 2020 10:04:04 -0600, Eric W. Biederman wrote: > >> > > Second. I looked at your test results and they don't directly make > >> > > sense. dmidecode bypasses the kernel completely or it did last time > >> > > I looked so I don't know why you would be using that to test if > >> > > something in the kernel is working. > >> > > >> > That must have been long ago. A recent version of dmidecode (>= 3.0) > >> > running on a recent kernel > >> > (>= d7f96f97c4031fa4ffdb7801f9aae23e96170a6f, v4.2) will read the DMI > >> > data from /sys/firmware/dmi/tables, so it is very much relying on the > >> > kernel doing the right thing. If not, it will still try to fallback to > >> > reading from /dev/mem directly on certain architectures. You can force > >> > that old method with --no-sysfs. > >> > > >> > Hope that helps, > >> > >> I don't understand how it possible can help for in-kernel code, like > >> DMI quirks in a drivers. > > > > OK, just ignore me then, probably I misunderstood the point made by > > Eric. > > No. I just haven't dived into this area of code in a long time. > > It seems a little indirect to use dmidecode as the test to see if the > kernel has the pointer to the dmitables, but with the knowledge you > provided it seems like a perfectly valid test. In any case that doesn't work. See my response to Ard. -- With Best Regards, Andy Shevchenko
