On Thursday, September 13, 2007 9:11 AM, Mark.Haywood at Sun.COM wrote: > Li, Aubrey wrote: >> On Thursday, September 13, 2007 1:56 AM, Dana.Myers at Sun.COM wrote: >> >> >>> So I took a look at the code (it's been a long time since I wrote >>> it, and I've forgotten how I implemented it). I originally feared >>> that I'd implemented the CPU mapping in a way that the 'duplicate' >>> Processor objects would confuse the mapping code. As you point >>> out, Mark, this is not the case. >>> You're completely correct, as far as I can tell - there's no reason >>> to ignore the Alias()ed Processor objects - they're just references >>> to the same object anyway. I admit I wasn't thinking of the case of >>> Alias() when I implemented the mapping code, but it doesn't make a >>> difference at all. >>> No memory is leaked, nothing is broken. >>> >>> Thanks - >>> Dana >>> >> >> That's not true, actually processor handler mapping is broken when >> an AliasObject exists. Although it is reference to the same object, >> it's another new object in the namespace. And it's not the parent of >> _PDC object. So when you passed it as the handler parameter to >> evaluate _PDC, >> We will run into the failure. >> > If this is true, then it seems to me that something must be wrong with > the acpica interpreter. According to the spec (as I read it > anyway), you > should be able to treat the alias just as you would the target. So, it > we cannot evaluate the _PDC using the alias object, then > again, I think > something is wrong at a higher level than where we are doing > the mapping > in osl.c >
What I see is acpica_add_processor_to_map() maps twice from object to handler, Firstly it maps P001 as processor handler. Secondly it maps CPU1 as processor handler, this moment the first time mapping is overwritten. Is this expected behavior? Do you think it's OK? -Aubrey
