linux-kernel - Re: [RFC] ARM Subarchitecture group maintainership

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]

Message-ID: <alpine.LFD.2.02.1105182313060.3078@ionos>
Date:	Wed, 18 May 2011 23:24:21 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
cc:	Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Russell King <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org, Nicolas Pitre <nico@...xnic.net>
Subject: Re: [RFC] ARM Subarchitecture group maintainership

On Wed, 18 May 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:47 Wed 18 May     , Arnd Bergmann wrote:
> > We will probably not be fully functional during the 2.6.40 merge window,
> > but we are trying our best to be useful. For 2.6.41, my hope is that
> > we can merge the bulk of the ARM subarchitecture changes through this
> > tree. Once Linus is happy with the way that the process works, we can
> > mandate that all ARM subarchitecture changes go through our tree, until
> > then it stays voluntary.
> How do you plan to manage with already sub arch maintainers?

The sub arch maintainers are not replaced by this.

> In my ming such tree could be good to organise cross arch drivers

This is not about drivers. drivers need to move out of arch/arm into
the proper drivers/subsystem where consolidation makes really sense
even across architectures. We have already multiple drivers for the
same stupid IP block in tree just because they were glued into
different SoCs (ARM, x86, ....). That's not an ARM specific problem,
it's all across the board, but on ARM it is very visible.

> but for real arch specific the current workflow is good

There is a difference between arch specific code - i.e. core ARM
architecture code - and SoC specific code which goes into
arch/arm/[mach|plat]-*. The core code was never and issue and we are
not touching it as Russell is handling it perfectly. The real issue is
the code in [mach|plat]-* which flows rather randomly into mainline
today. That results in lack of review, push back and makes
consolidation as hard as it gets.

> If we add a new stage it will be difficult to follow for people

What is difficult about that? How does it matter whether you ask A or
B to pull and propagate your subarch code?

> I'd like to have scenario example where such workflow will give a significant
> advantage compare to the current workflow. And please real example.

See above. It's not about examples, it's about solving issues like
lack of review, lack of central places to do consolidation work and
lack of push-back when stuff goes into the wrong direction.

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/