[flashrom] DMI matching patch

Luc Verhaegen libv at skynet.be
Thu Jan 7 12:22:36 CET 2010

On Thu, Jan 07, 2010 at 11:16:14AM +0100, Michael Karcher wrote:
> Am Donnerstag, den 07.01.2010, 10:25 +0100 schrieb Luc Verhaegen:
> > > > I'm not so happy about the static allocation here. Can't we use malloc()
> > > > for the read buffer and strdup() for filling in dmistrings?
> > > Of course we can. On the other hand, I don't really see the point in
> > > using dynamic allocation here. If it's about wasted memory, we should
> > > approach "struct flashchips" first. The fixed-size arrays in it waste a
> > > lot more. Nevertheless, I change it to dynamic allocation. Too bad the
> > > nice getline function that reads one line and allocates dynamically is
> > > GNU-only and not standard C or at least POSIX.
> > This is a run-once tool, the results are not stored, and we do not go 
> > and run dmidecode several times. Everything filling up any memory should 
> > be ran once.
> Sorry, I don't really understand your statement in this context. We do
> not run dmidecode once, but once for each string that might be
> interesting, because the machine-readable "-s" interface of dmidecode
> can only return one string at once. That's six invocations of dmidecode
> per flashrom start. The strings are collected during flashrom
> initialization and kept. The context of what you were replying to was
> whether the 6 dmi strings are stored in a statically allocated buffer or
> in 6 buffers allocated by malloc.

Ok, then each of those 6 strings are only stored once, and are always 
stored (if dmidecode is present), the never need to get used for other 
purposes, they never need to get removed and re-added with other 
contents. They are local to the dmi.c code. I do not see a reason to 
make them dynamically allocated.

> > That's way too contrived for my taste.
> That's what I expected, and that's why I didn't commit yet. I won't
> commit until you and Carl-Daniel agree on the necessity of providing
> which string to match, although I slightly prefer the explicit
> specification of the string to match.
> > If you really believe it is 
> > necessary, then you should provide an enum entry right in front of the 
> > string.
> Yeah. This would make the data structure cleaner...
> > But then the board enable table is taking another big hit, and this i 
> > would like to avoid at all cost.
> ... but I avoided it for exactly this reason. Especially because it will
> add only one empty column on boards that don't need DMI matching.
> > We already have pci ids and pci subsystem ids, this is just an extra
> > bit of info that will be the last in precedence for any match.
> Looking at the Asus P5A example (I know that this board is severly
> outdated, which might make this point less strong) there are no
> subsystem IDs at all in it. So when we start looking for DMI info we
> don't have any indication yet that we are on an Asus board. If we really
> have good subsystem IDs, we don't need DMI.

Yeah, maybe a few of the other boards which can only be matched 
with -m can also be improved this way.

Luc Verhaegen.

More information about the flashrom mailing list