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

[Ingo Molnar]

* Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:

> On Tue, 30 Jun 2009 08:35:13 +0200
> Pavel Machek <pavel@xxxxxx> wrote:
> 
> > On Fri 2009-06-26 09:54:54, Jesse Barnes wrote:
> > > On Fri, 26 Jun 2009 18:32:42 +0200 (CEST)
> > > Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> > > 
> > > > On Fri, 26 Jun 2009, Ingo Molnar wrote:
> > > > > [ Although it is beyond me why ABP was done - why wasnt HPET
> > > > > good enough? HPET can do per CPU clockevents too and it's just
> > > > > as off-chip (and hence fundamentally slow) as ABP. ]
> > > > 
> > > > Welcome to the wonderful world of embedded systems. Just have a
> > > > peek into arch/[arm/powerpc/mips] to see what's coming up to us
> > > > with full force. I would not be surprised when we see an x86
> > > > system sharing the device driver for i2c or whatever with an ARM
> > > > SoC in the foreseable future.
> > > 
> > > Ha, yeah I was just going to say "think embedded".  ABP is a much
> > > simpler spec and programming interface than HPET, and since we were
> > > designing new custom silicon, it made sense to just do the simple
> > > thing, rather than butchering an existing spec, then making a
> > > partial HPET that looks like ABP anyway and forcing any future HPET
> > > updates to conform to the new standard (very similar reasoning to
> > > the ACPI vs SFI discussion btw).  Hopefully the technologies we've
> > > come up with for
> > 
> > Very similary wrong, I'd say :-(. While you could have created
> > hpet-lite, where hpet-lite driver would work on hpet system, you went
> > and created something new.
> > 
> > And yes, SFI is similar disaster, you should just define subset of
> > acpi ('acpi-lite').
> > 
> > In the end, you are willing to use silicon for compatibility (arm
> >  instruction set needs less transistors, right?) and wasting millions
> >  of transistors, then try to save thousands with non-compatible
> >  devices :-(.
> 
> You didn't address the essence of either argument; butchering an 
> existing spec and placing an extra burden on all future 
> implementations is a high price to pay, both in terms of 
> complexity and cost.
> 
> But really these are moot points; this is how the platform works.  
> I'd like to see Linux run on it "out of the box" which means 
> integrating support for these features in a maintainable way.  
> Hopefully no one disagrees with that; after all Linux runs on much 
> uglier platforms than this.

I agree and that's fine.

Note that obviously ugliness increases the integration costs and 
latency for Intel: all ugly bits have to be factored out cleanly, 
have to be turned into isolated components and tucked away, so that 
the ugliness does not spread.

If something is just plain 'standard', that makes it really easy to 
merge. The less standard something is, the more trouble integration 
becomes.

Also, i genuinely think that it's perfectly fine to iterate hardware 
specs - to simplify and enhance it. And this is an area where Linux 
is the strongest - we can support just about anything and can do it 
quickly. I just wish that those variations were something to be 
unconditionally proud of from an engineering POV ;-)

So for similar projects in the future - it's OK to be non-standard, 
but the preferred direction should be something genuinely better 
designed, or something that is just a _sub-set_ of the standard. 
Supporting a sub-set is way easier than supporting something that is 
different in some unanticipated way and needs an extension of 
infrastructure.

The IO-APIC bits seems to be the latter in this case - i.e. they are 
an "IO-APIC light" implementation in essence. And that shows 
immediately: the patches arent all that horrible.

And SFI seems useful to me as well, not because it's a sub-set of 
ACPI, but because i find it cleaner than ACPI.

The ABP timer is another matter - it's a completely separate 
from-scratch thing that is dissimilar to everything that exists. 
OTOH, timers are pretty separate entities just (still) not 
abstracted out well enough on x86 yet.

	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/