Re: [PATCH 3/9] x86/moorestown: add moorestown platform 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.

Good the boot loader knows precisely what it is running on

Using boot flags is one of the lowest quality enumeration methods

It's probably the most reliable. If you don't believe so then provide
data to back your assertion

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.

How about "they tried other methods and they didn't work"

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)

I claimed nothing of the sort Ingo. I pointed out your approach doesn't
actually work except for the PCI case. WHich means it doesn't even work
on a generic 486 ISA bus PC. Is that a single chip embedded device using
a licenced core from one of the 486 vendors or an ISA PC .. how do you
tell.

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.

You try one, that I/O address isn't mapped and you get a fatal machine
check. Exactly why is that reliable ?

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.

PCI is already obsolete.

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.

You only have an EBDA on a PC type machine. You only have ACPI on a PC
type machien. You only have EFI ona PCI type machine. So how will you
look for them when the generic whacky BIOS windows for 16bit DOS
compatibility that hold these things might be ROM or random chunks of
main memory ?

SFI doesn't indicate MRST

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

If you have the bootloader pass the information then that is one source
of it. It doesn't need to be the only one.

You are also pointlessly entangling MRST and platform identification.

Please separate out the following in your thinking

- How you implement int platform = gee_what_the_hell_am_i_running_on()

and "ok so I'm a voyager, now what"

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.

I'm trying to sort out the broader question.

It's called architecture - planning for the future, design. If you want
to be utterly narrow minded you can NIH about every platform but x86 and
pretend hardware won't exist that doesn't fit your predetermined vision.
If you don't plan for the future you get to write the arch code every new
hardware platform. Which is fun and you really want to spend your life
re-inventing this every six months no ?

Non-x86 ultra-embedded might use crappier techniques but i'd expect
Intel has the resources to do better here. Using standard hardware

What makes you think x86 ultra-embedded is solely an Intel thing. OLPC
isn't Intel for one although its still quite PCish.

or firmware interfaces for that is far better in the x86 space and
we have no reason to depart from that really.

It isn't about departing from that, it's about supporting the future. If
you untangle this into two questions

- How do I identify this platform

- How do I run on lots of platforms without the code becoming a
mess

it might make more progress.

The important one right now is the second question. Whether you set the
platform on dip switches or by PCI bus probing the interface doesn't
change. Its a function that returns a number.

The hardware interfaces don't exist in x86 unlike most other
architectures so that does need addressing properly and can't be deferred.

--
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/

Relevant Pages

  • Re: Use of virtio device IDs
    ... are different in a virtualized platform, so some things do not translate ... The point of PV, of course, is high performance guest/host interfaces, ... and PCI baggage just gets in the way in many respects. ... way by PCI (or by any good hardware bus protocol). ...
    (Linux-Kernel)
  • Re: Variable hoisting (Updated results...)
    ... * will require attention if ported to another platform. ... this is absolutely necessary (almost never in apps, ... > run is now MD'd and hardware spares are not ... hardware concerns at all) rack-mount Intel or AMD based-server, ...
    (comp.programming)
  • Re: A One-Console Future? No Xbox, No PS3, No Wii? (article)
    ... Just like there's only OS and one hardware platform for PCs... ... massive paradigm shift to the industry,where games would become better ... Console games still tend to evolve pretty fast as compared to other ...
    (alt.games.video.xbox)
  • Re: What will many cores mean to future Windows releases?
    ... If developers cannot take care to write efficient code in language X, that uses physical memory management of the underlying hardware and/or OS level calls, then they will likely not be competent to write VM code. ... An OS might in theory be a hardware abstraction layer, but in reality, I can't think of another OS besides CP/M that was intentionally created to evade hardware vendor lock in. ... (And the same is completely true of IBM-DOS--that IBM lost control of the platform was certainly to MS's advantage, but the real enablers were the AMI and Phoenix BIOSs. ... Languages are usually not developed with a particular OS in mind. ...
    (borland.public.delphi.non-technical)
  • Re: [PATCH] [REPOST] timer iomem hwrng driver
    ... had a source that provided new data at intervals of time where jiffies ... Of course I should handle the wrap case, which I have already done at ... 64bit on a platform or two. ... actually have the necessary hardware? ...
    (Linux-Kernel)