linux-kernel - Re: Tracing Requirements (was: [RFC/Requirements/Design] h/w error reporting)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Nov 2010 10:17:04 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	"Luck, Tony" <tony.luck@...el.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Huang, Ying" <ying.huang@...el.com>,
	"bp@...en8.de" <bp@...en8.de>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"mchehab@...hat.com" <mchehab@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: Tracing Requirements (was: [RFC/Requirements/Design] h/w error
 reporting)

* Thomas Gleixner <tglx@...utronix.de> wrote:

> On Wed, 10 Nov 2010, Mathieu Desnoyers wrote:

> > I'd like to start with an implementation that skips some of these requirements 
> > initially, but what I really think we need to figure out is how we organize our 
> > ABIs to finally support these requirements.

Note, there is an existing ABI in place, please use that. (It's highly extensible so 
it can support just about any ABI experiment that can even be turned into a smooth 
ABI replacement.)

I think Frederic just started iterating it - but if Mathieu and Steve helps out it 
will all happen faster.

> I did not say, that you should not think about this, but the progress so far in 
> more than TWO YEARS is exaclty ZERO. And that's what I'm concerned about.

Yes, indeed that is the main problem i see as well.

Most of the problems listed in the various documents can be solved iteratively in 
the existing facilities. There is not a single requirement where Peter or me said 
'No, this cannot be done, go away!'. Each and every item was answered with: 'sure, 
we can do that' - or at worst with a 'do we really need it?'. Each and every item 
fits naturally into existing goals as well - so it's not like some different world 
view is being forced on anyone.

We only have one basic condition: please introduce these thing step by step in the 
existing ABI.

This is a must-have for tools, and there is another very important factor as well: a 
couple of items can have disadvantages beyond the claimed advantages, so we want to 
be able to evaluate the effects in isolation, test them and if needed, undo them. It 
will settle the 'do we really need this?' kind of sub-arguments for sub-features.

So being intelligent about it, being iterative is my only requirement to you guys: 
you are free to change anything, go wild, but please make it iterative and dont try 
to fork the tooling and developer community.

The time has come to not grow the list of requirements but to shrink it.

Thanks,

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