lkml.org 
[lkml]   [2009]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/9] x86/moorestown: add moorestown platform flags

* Alan Cox <alan@lxorguk.ukuu.org.uk> 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


\
 
 \ /
  Last update: 2009-06-26 13:07    [W:0.607 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site