linux-kernel - Re: [PATCH 0/4] WorkStruct: Shrink work

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <10106.1164108498@redhat.com>
Date:	Tue, 21 Nov 2006 11:28:18 +0000
From:	David Howells <dhowells@...hat.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	David Howells <dhowells@...hat.com>, torvalds@...l.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] WorkStruct: Shrink work_struct by two thirds 

Andrew Morton <akpm@...l.org> wrote:

> Could we reduce the migration pain by leaving the work_struct as-is and
> defining a new, leaner one and then incrementally migrating stuff over to
> it?

That involves more work in the end for a number of reasons:

 (1) The more common use (I think) is the immediate, not the delayed work
     item.  One of them has to change, and it'd make sense for it to be the
     latter.

 (2) The internals of kernel/workqueue.c all refer to work_struct.  They'd all
     have to change as that'd no longer be the common bit.

 (3) All the work callback functions have to change anyway, and they have to
     be handed the most common structure as their context - assuming the third
     reduction is acceptable.

 (4) All the initialisers have to change anyway as they take one fewer
     argument - assuming the third reduction is acceptable.

It'd be more feasible if the inventors of C had included C++-style function
overloading and structure inheritance, but they didn't.

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