Re: [PATCH 3/9] x86/moorestown: add moorestown platform flags

[Ingo Molnar]

* Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:

> > It's an entirely legitimate question, given that many other 
> > current modern subarchitectures detect themselves based on PCI 
> > config space early accesses or (sometimes) BIOS data structures 
> > - and that both of those methods are better than using boot 
> > flags.
> 
> The flags are passed by the boot loader which is the one thing 
> that knows what the platform is only deeply embedded hardware. See 
> the ARM and PPC ports.

And? There's an obvious quality difference between various platform 
enumeration methods - and we strive for the highest quality methods.

Using boot flags is one of the lowest quality enumeration methods 
and the fact that there's precedence for it in other architectures 
is not a technical reason to make the same mistakes on x86 too.

Especially here where there's two other enumeration methods easily 
available: SFI and PCI. Any of those suffices.

> > > - Embedded x86 like devices are going to regularly occur 
> > > without any PCI
> > 
> > This proposed Intel subarchitecture comes with PCI support, 
> > obviously.
> 
> And this is relevant to the fact there will be systems without PCI 
> how ?

It is obviously relevant to the fact that the proposed patches here 
(on which i commented) come for a platform with PCI support. Or do 
you claim that Intel submitted this patch-set for PCI-less MIDs? 
(this was not mentioned anywhere in the patches)

> > > - You need to know the platform in order to know how to access 
> > >   any PCI bus that may or may not hypothetically exist.
> > 
> > Uhm, not really.
> 
> Uhm yes really
> 
> > Have a look at arch/x86/kernel/early-quirks.c. All you generally 
> > need to know is a PCI ID that sits on the root bus.
> 
> How will you probe the root bus without knowing what the PCI 
> configuration mechanism is for your platform

That's very simple really - there's basically a very low number of 
PCI configuration mechanisms/ports on x86, and the MIDs have no 
reason to depart from that standard. There's two that matter in 
practice, and it can all be safely probed.

PCI is really essential to any modern architecture (precisely 
because it's standard and well-known) and i doubt Intel will try to 
engineer out PCI from its systems. If it happens i will comment on 
that kind of braindamage in due course.

But, PCI IDs dont _have_ to be used - there's ample other 
environmental space available via SFI, ACPI or EFI or old-and-proven 
EBDA.

> > Early PCI ID checks are typical and robust way to identify 
> > 'weird' subarchitectures. Sometimes we do it via BIOS data 
> > structures. Only as a last option do we want to use boot loader 
> > mechanisms - it's the most inflexible one really.
> 
> SFI doesn't indicate MRST

So do you claim that this particular patchset supports systems with 
no SFI, no ACPI, just plain bootloader flags?

> > Furtherore, Moorestown comes with SFI and there sure can be a 
> > BIOS table that describes the platform properly. We can read 
> > such tables very early during bootup, well before platform 
> > devices are set up.
> 
> But they don't tell you what the platform is. Again see every 
> platform we currently support which has deeply embedded forms. 
> There is a reason they went that way and it includes fifteen years 
> of finding out which ways don't work for all cases. For example if 
> you don't have standard PC like firmware and you go looking for 
> SFI or ACPI will your box stay up ?

Do you claim that the Intel patchset here deals with systems that 
have no SFI and no ACPI? My question was very specific to this 
patch-set. Bootloader flags suck because they add a needless 
dimension to the already complex boot protocol. Use existing 
mechanisms instead - it's really easy and has other advantages as 
well.

Non-x86 ultra-embedded might use crappier techniques but i'd expect 
Intel has the resources to do better here. Using standard hardware 
or firmware interfaces for that is far better in the x86 space and 
we have no reason to depart from that really.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/