It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you

Unfortunately, I don't a have single term that would adequately convey the idea. Greg and I were batting around some invented words (e.g. "poption" as a portmanteau of profile-option was my first

Slimming down the CC list a bit, as this is off topic for some lists. I'm in the process of getting status from the new Unified Discovery

Identifier in the sense of a short name/phrase that refers to these ideas. Consumers of that would be both software and day-to-day discussion as it's a succinct identifier that refers to an idea in

Correct. Do you have a better term that captures such notions? I fully agree that the previous definition of an extension is not the same in this case. FWIW, the profile spec uses both 'extensions'

Hi Aaron, Since the ECRs need to be submitted as word doc, the plan was to archive the notes/comments and ECR versions in the gdrive itself. Please

To add on to Alan's point. These "extension" names were created simply to represent individual line items in the Profiles. In many cases these represent a one or two sentence statement in a Profile

I'm also unclear of the "identifier" you mention for other unmentioned option value (e.g. your 64b cache block size example). Who is the consumer of that identifier? Is this a value you would expect

If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense. They are names for the values of architectural options of extensions that already

Got it. I understand what you are saying now and agree. regards ved

Hi Aaron, Few comments below ... Rather than gating these ACPI ECR efforts on AIA spec being frozen. We should start sending out incremental ECRs for the things that are already ratified. Each ECR

Does the Unified DIscovery Specification exit yet? Where can I find it? Best regards Heinrich

Just that UD is the source for filling in everything. In my words foundational and not just orthogonal. I didn't see it below in, for example, discussions about ISA strings. I wanted to make sure that

I would also expect to have the OS make the UD message (in its raw, unparsed form) available to userspace consumers. In other words: even if the OS works off DT/ACPI tables, the full information

As per my understanding, early boot refers to OS world. Introducing UD to the S-mode is not an option in my opinion. We already have all the infrastructure for DT/ACPI in rich OS land. As Phillip

I think of UD being orthogonal to this discussion. Firmware world | OS world | [UD, etc. ]---firmware builds-+->[ACPI/DT]--->OS

agreed. but it all starts with UD. we had every extension devising their own discovery mechanism and everyone agreed that was not the correct thing to do. We reduced UD this year to just ASN and

Unified DIscovery is expected to be used by firmware to populate DT and ACPI/UEFI tables. Philipp.

just a reminder that we should be moving to unified discovery during boot to feed everything. not isa strings. not csrs. -------- sent from a mobile device. please forgive any typos.

Hi, I'm top posting with some notes that Furquan helped me put together to cover the things we've been talking about. We may want to put these and future notes somewhere else (drive, github, etc) so