dmidecode-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dmidecode] [Patch 0/4] dmidecode: add dmi sysfs support


From: Jean Delvare
Subject: Re: [dmidecode] [Patch 0/4] dmidecode: add dmi sysfs support
Date: Thu, 26 Feb 2015 12:02:54 +0100

Hi Ivan, Anton,

On Thu, 05 Feb 2015 16:52:32 +0200, Ivan Khoronzhuk wrote:
> On 02/04/2015 04:46 PM, Anton Arapov wrote:
> > I’m fine with the patchset in general. Though I don’t like moving the
> > memory allocation to smbios_decode(), it dupes the code and doesn’t
> > help reading. But I can live with this.
> 
> It dupes a little, but it simplifies dmi_table_dum() in the same time.
> 
> >
> > I do not want to have an extra depenendency on libmifs too. dmidecode
> > as a tool meant to be self-sufficient. We might want to get the dmifs
> > implementation into dmidecode.
> >
> > Jean, what is your opinion here?

I thought I had replied already but the list archive is pretty positive
that it only happened in my dreams. Sorry about that. So I am replying
now for completeness, even though I will just repeat what I said in
other threads earlier today.

I agree with Anton, I don't want to depend on a library either. Firstly
because dmidecode was meant to be independent from the beginning, and
secondly (most importantly) because requiring a library is a clear
indication that you are doing something wrong.

Getting the data you need from sysfs instead of /dev/mem is a good move
IMHO, and I will support that. But all you need in order to achieve
that is to let the kernel code export the entry point and the DMI table
as binary files. Plugging dmidecode on top of that should be pretty
straightforward and should certainly not take a 4-patch set plus a
library.

-- 
Jean Delvare
SUSE L3 Support



reply via email to

[Prev in Thread] Current Thread [Next in Thread]