Date:	Fri, 24 Aug 2012 17:18:14 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Attilio Rao <attilio.rao@...rix.com>
cc:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Borislav Petkov <bp@...en8.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
	Stefano Stabellini <Stefano.Stabellini@...citrix.com>
Subject: Re: [PATCH v4 1/2] XEN/X86: Improve semantic support for
 x86_init.mapping.pagetable_reserve

On Fri, 24 Aug 2012, Attilio Rao wrote:
> On 24/08/12 14:00, Thomas Gleixner wrote:
> > On Fri, 24 Aug 2012, Konrad Rzeszutek Wilk wrote:
> >    
> > > His goal was to document the semantics of the call. We all want to clean
> > > up the mess of extra calls that don't make sense (remember the
> > > write_msr_safe one?) and the first step is get some of the calls
> > > documented so that we know if some of these calls can be moved around
> > > for refactoring. Attilio went then beyond that being enthuastic about
> > > this and wrote logic to deal with the description of the semantics.
> > > In part this would help the refactoring as it would catch runtime
> > > issues.
> > >      
> > No. His logic to deal with the semantics started to imply wrong and
> > silly semantics in the first place. What's the point of making a
> > function deal with A != B, where A is required to be equal to B. We do
> > not add special cases for stuff which cannot happen neither on
> > baremetal nor on XEN. Period.
> >    
> 
> Please stop referring to your opinion as if they are the only source of truth.
> Actually here is a matter of comparing prices. We thought accounting for
> different { start, end } was a viable option, you want something simpler and
> as a x86-maintainer you enforce your opinion over here. But this doesn't mean
> what the patch does is "wrong".

As long as the pgt_buf logic is as it is, the allocation starts from
pgt_buf_start and from nowhere else. If you want to change that, then
you have to fix way more than the reserve_function. That part is going
to be the least of your worries.

I'm not enforcing my opinion, I'm pointing to facts and I'm refusing
to take patches which are semantically wrong and try to create
semantics which are detached from the reality.

Stop arguing and just admit that your semantical crusade is just a
failure. 
 
> > > That is at odds with what Peter would like to have fixed:
> > > (from
> > > http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/000070.html)
> > > "
> > >     Hooks and notifiers are a form of "COME FROM" programming, and they
> > >     make it very hard to reason about the code.  The only way that that
> > >     can be reasonably mitigated is by having the exact semantics of a
> > >     hook or notifier -- the preconditions, postconditions, and other
> > >     invariants -- carefully documented.  Experience has shown that in
> > >     practice that happens somewhere between rarely and never.
> > > 
> > >     Hooks that terminate into hypercalls or otherwise are empty in the
> > >     "normal" flow are particularly problematic, as it is trivial for a
> > >     mainstream developer to break them.
> > > "
> > >      
> > I'm not against documentation. I'm against wrong documentation, wrong
> > and silly semantics and pointless code which tries to deal with cases which
> > are just wrong to begin with.
> > 
> > I looked at the whole pgt_buf_* mess and it's amazingly stupid. We
> > could avoid all that dance and make all of that pgt_buf_* stuff static
> > and provide proper accessor functions and hand start, end, top to the
> > reserve function instead of fiddling with global variables all over
> > the place. That'd be a real cleanup and progress.
> >    
> 
> Assuming that having a bunch of static variable in boot-time code is "clean"
> in your head (and certainly it is not in mine) ...

What the hell is the difference between a global variable which is
touched in boot-time code and a static variable ?

It's the same, except that the scope is a different one. And it's way
easier to enforce semantics on a limited scope than on a global one.

And that confinement cannot happen, because XEN already depends on
that global variables in a really messy way.
 
> > If anything is missing a semantic documentation and analysis then
> > definitely code like this which is just a cobbled together steaming
> > pile of ....
> >    
> 
> Look, when it cames to "comparing prices" situation I can reimplement things
> in the way you prefer, but here it seems you are just going out of the line
> without a real reason and certainly that was uncalled for.
> 
> What I want to understand now is: are you favorable in taking into tips a
> different patch to x86_init.mapping.pagetable_reserve semantic or you would
> not consider it just on the basis that other xen-related code doesn't behave
> the way you like, without giving any real technical objection?

I gave enough technical objections. Stop wasting anyones time already.

Thanks,

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

Powered by blists - more mailing lists