| 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
| ||
|
Message-ID: <20081218081029.GA20336@ioremap.net> Date: Thu, 18 Dec 2008 11:10:29 +0300 From: Evgeniy Polyakov <zbr@...emap.net> To: Benjamin Herrenschmidt <benh@...nel.crashing.org> Cc: Arnd Bergmann <arnd@...db.de>, Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com> Subject: Re: [4/7] dst: thread pool. Hi Ben. On Thu, Dec 18, 2008 at 11:51:47AM +1100, Benjamin Herrenschmidt (benh@...nel.crashing.org) wrote: > Heh. I think I counted 3 or 4 thread pool implementations already in the > kernel though they are all ad-hoc attached to a given subsystem. 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 :) -- Evgeniy Polyakov -- 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