Re: [m5-dev] Review Request: config: revamp x86 config to avoid appending to SimObjectVectors
On 2011-03-26 12:31:49, Gabe Black wrote: src/arch/x86/bios/E820.py, line 53 http://reviews.m5sim.org/r/609/diff/1/?file=11254#file11254line53 I think at least most of these lists should be allowed to be empty regardless of if they're being appended to. Steve Reinhardt wrote: They're still allowed to be empty... the question is, does that make sense as a default value? Would the system work with these parameters left as the empty list? If so, I can put that back. For int_lines it definitely does since that's just for making sure interrupt lines are instantiated by making sure they have a parent. Those are objects that avoid cycles of simobjects by pointing outwards to their two ends. The ends don't refer the line object, so no cycle can cross it. The side effect is that nothing inherently refers to the line itself, so those need to be explicitly parented somehow. I put them all in a VectorParam to get them all at once instead of making up junk names for everything individually. The E820 table entries make less sense to be empty since you don't have much of a table with no entries. There may be a situation where you want to have a place holder E820 table with nothing in it since you have to have it as a parameter to something but don't want to actually have a table. The E820 table is provided by the BIOS through an interrupt call where I think ax is set to e820 or something like that. It provides entries which describe regions of memory that exist and labels them as available for use, reserved, or one of two types related to ACPI, if I remember correctly. A table like that is pretty important, but as I said I can imagine when you'd want to be able to have an empty one. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/609/#review1019 --- On 2011-03-26 12:17:28, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/609/ --- (Updated 2011-03-26 12:17:28) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- config: revamp x86 config to avoid appending to SimObjectVectors A significant contributor to the need for adoptOrphanParams() is the practice of appending to SimObjectVectors which have already been assigned as children. This practice sidesteps the assignment operation for those appended SimObjects, which is where parent/child relationships are typically established. This patch reworks the config scripts that use append() on SimObjectVectors, which all happen to be in the x86 system configuration. At some point in the future, I hope to make SimObjectVectors immutable (by deriving from tuple rather than list), at which time this patch will be necessary for correct operation. For now, it just avoids some of the warning messages that get printed in adoptOrphanParams(). Diffs - configs/common/FSConfig.py d8587c913ccf src/arch/x86/bios/E820.py d8587c913ccf src/dev/x86/SouthBridge.py d8587c913ccf Diff: http://reviews.m5sim.org/r/609/diff Testing --- Thanks, Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: config: revamp x86 config to avoid appending to SimObjectVectors
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/609/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- config: revamp x86 config to avoid appending to SimObjectVectors A significant contributor to the need for adoptOrphanParams() is the practice of appending to SimObjectVectors which have already been assigned as children. This practice sidesteps the assignment operation for those appended SimObjects, which is where parent/child relationships are typically established. This patch reworks the config scripts that use append() on SimObjectVectors, which all happen to be in the x86 system configuration. At some point in the future, I hope to make SimObjectVectors immutable (by deriving from tuple rather than list), at which time this patch will be necessary for correct operation. For now, it just avoids some of the warning messages that get printed in adoptOrphanParams(). Diffs - configs/common/FSConfig.py d8587c913ccf src/arch/x86/bios/E820.py d8587c913ccf src/dev/x86/SouthBridge.py d8587c913ccf Diff: http://reviews.m5sim.org/r/609/diff Testing --- Thanks, Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: config: revamp x86 config to avoid appending to SimObjectVectors
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/609/#review1019 --- src/arch/x86/bios/E820.py http://reviews.m5sim.org/r/609/#comment1388 I think at least most of these lists should be allowed to be empty regardless of if they're being appended to. - Gabe On 2011-03-26 12:17:28, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/609/ --- (Updated 2011-03-26 12:17:28) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- config: revamp x86 config to avoid appending to SimObjectVectors A significant contributor to the need for adoptOrphanParams() is the practice of appending to SimObjectVectors which have already been assigned as children. This practice sidesteps the assignment operation for those appended SimObjects, which is where parent/child relationships are typically established. This patch reworks the config scripts that use append() on SimObjectVectors, which all happen to be in the x86 system configuration. At some point in the future, I hope to make SimObjectVectors immutable (by deriving from tuple rather than list), at which time this patch will be necessary for correct operation. For now, it just avoids some of the warning messages that get printed in adoptOrphanParams(). Diffs - configs/common/FSConfig.py d8587c913ccf src/arch/x86/bios/E820.py d8587c913ccf src/dev/x86/SouthBridge.py d8587c913ccf Diff: http://reviews.m5sim.org/r/609/diff Testing --- Thanks, Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: config: revamp x86 config to avoid appending to SimObjectVectors
On 2011-03-26 12:31:49, Gabe Black wrote: src/arch/x86/bios/E820.py, line 53 http://reviews.m5sim.org/r/609/diff/1/?file=11254#file11254line53 I think at least most of these lists should be allowed to be empty regardless of if they're being appended to. They're still allowed to be empty... the question is, does that make sense as a default value? Would the system work with these parameters left as the empty list? If so, I can put that back. - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/609/#review1019 --- On 2011-03-26 12:17:28, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/609/ --- (Updated 2011-03-26 12:17:28) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- config: revamp x86 config to avoid appending to SimObjectVectors A significant contributor to the need for adoptOrphanParams() is the practice of appending to SimObjectVectors which have already been assigned as children. This practice sidesteps the assignment operation for those appended SimObjects, which is where parent/child relationships are typically established. This patch reworks the config scripts that use append() on SimObjectVectors, which all happen to be in the x86 system configuration. At some point in the future, I hope to make SimObjectVectors immutable (by deriving from tuple rather than list), at which time this patch will be necessary for correct operation. For now, it just avoids some of the warning messages that get printed in adoptOrphanParams(). Diffs - configs/common/FSConfig.py d8587c913ccf src/arch/x86/bios/E820.py d8587c913ccf src/dev/x86/SouthBridge.py d8587c913ccf Diff: http://reviews.m5sim.org/r/609/diff Testing --- Thanks, Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
