linux-kernel - Re: [4/7] dst: thread pool.

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] [day] [month] [year] [list]

Date:	Thu, 18 Dec 2008 10:44:27 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Evgeniy Polyakov <zbr@...emap.net>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com>
Subject: Re: [4/7] dst: thread pool.

On Thursday 18 December 2008, Evgeniy Polyakov wrote:

> That's how such projects are implemented: when developers need to
> extend some other sybsystem they do that with own implementation of the
> needed feature. Moreover people frequently argue against importing some
> new feature if there are no direct users of it (like may happen with
> thread pools, which no one will use immediately), so why bother with
> that crap (och, well, and interfaces, there will be definitely people
> who do not like them) when it is possible just to make working what
> you like? So I fully understand those who implemented it in theirs
> subsystems. I would even call blaming them for not pushing theirs
> implementations into generic location somewhat hypocritically because
> of above :)

I agree, and I don't think anyone has done anything wrong so far with
this. The natural way that internal features get into the kernel is
roughly:

1. Someone needs a feature and does a minimal implementation suiting
a specific purpose.
2. A few other people implement something similar, in slightly
different ways.
3. One of the implementations gets mentioned in a howto or a textbook
and people start copying from that.
4. One person gets fed up with the duplication and proposes a generic
solution as a patch.
5. After some discussion, this or another implementation gets merged.
6. The majority of the previous implementations get moved over to
the common code.
7. During that process, a deficiency in the interface gets noticed
and it gets changed again, forcing everyone who moved over to also
change again.

We are currently in stage 2, and I'm not sure if it's even a good idea
to skip any of the following stages. If we're lucky, we can skip stage 3.

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