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:	Tue, 12 May 2015 14:49:10 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Josh Triplett <josh@...htriplett.org>,
	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCHv2 1/2] clone: Support passing tls argument via C rather
 than pt_regs magic

On Tue, 12 May 2015 23:38:43 +0200 Peter Zijlstra <peterz@...radead.org> wrote:

> > What happens quite frequently is that we do something for x86 with the
> > expectation that other architectures will follow along, but this
> > doesn't happen.  The arch maintainers simply didn't know about it or
> > nobody nags them.  Nothing happens and inconsistencies hang around for
> > years.  eg, http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04993.html
> > 
> > I'm thinking we should find a way to do this better.  One way might be
> > to maintain a Documentation/arch-todo which identifies each item, has a
> > little list of what-to-do instructions and perhaps a list of the
> > not-yet-done architectures.  Basically a way for everyone to
> > communicate at the arch maintainers.
> 
> If only there was a linux-arch list to which arch maintainers should
> subscribe... oh wait :-)

It was I who got linux-arch established, so I'm fairly familiar with
it.  (12 years ago, gad).

I don't think it's been very successful, particularly for this purpose.
A whole pile of randomly cc'ed lkml overflow which we're relying on each
individual maintainer to sift through and pluck out particular action
items then later remember to implement them.  It's disorganized and has
too many cracks for things to fall through.


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