[PATCH] fix mapping of chassitype to system.formfactor

[Danny Kukawka]

On Monday 08 May 2006 17:54, David Zeuthen wrote:
> On Fri, 2006-05-05 at 17:48 +0200, Danny Kukawka wrote:
[...]
> and I'm not sure why we need locking.

I couldn't find a other 100% secure way to avoid this problem without a 
onetime lock. 

> Maybe the ACPI/PMU/APM code is setting system.formfactor when it
> shouldn't (e.g. in step 1 rather than step 2). Also, what about
> synthesizing the events we need *after* we added the computer object?
> Any chance you can look into that?

No, I think the ACPI/APM/PMU code is correct. The problem is, that the 
information for mapping smbios info to system.formfactor are from the prober 
which call dmidecode and need to parse the information from this output to 
fill the needed keys. IMO you can't say how long this need, because the 
prober run while HAL do other things (like synthesizing ACPI events/devices) 
without a lock you can't be sure that a other part write information while 
this code do the mapping. I debugged this 'race' and the info from ACPI acpi 
is written before the mapping start. I see no other way to fix this atm.

Cheers,

Danny