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:	Fri, 21 Nov 2008 08:49:29 -0600 (CST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
cc:	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH RFC] cpu alloc cleanups and implementation improvement

On Fri, 21 Nov 2008, Stephen Rothwell wrote:

> > I would not mind if you would take over from here.
>
> So, should I remove the cpu_alloc tree from linux-next?

I think the cpu_alloc branch itself is fine because it only contains the
allocator and a single use case. The only point of disagreement at this
point is the uppercase / lowercase use. Currently its a separate API (its
not replacing allocpercpu) and therefore easy to merge.

The more invasive stuff is stage2 and the following which is not in next
yet. The way I envision to go forward is with a gradual transition to the
new APIs converting dynamic percpu users to use the new percpu operations
and functionality.

The whole thing becomes riskier if we directly replace all allocpercpu
users as proposed by Rusty.

Rusty, are you going to take this on?

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ