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]
Message-ID: <9685.1164107326@redhat.com>
Date:	Tue, 21 Nov 2006 11:08:46 +0000
From:	David Howells <dhowells@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Trond Myklebust <trond.myklebust@....uio.no>,
	David Howells <dhowells@...hat.com>, torvalds@...l.org,
	akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] WorkStruct: Shrink work_struct by two thirds 

Christoph Hellwig <hch@...radead.org> wrote:

> > Why not simply add a timer argument to 'queue_delayed_work()' and
> > 'cancel_delayed_work()'? That may allow you to reuse an existing timer
> > struct if you already have it embedded somewhere else.
>
> I doubt we can really reuse an existing timer,

I have to agree with Christoph on that.  I don't think reusing an existing
timer is going to work in most of the cases - in many cases there isn't an
existing timer to reuse, and even if there is, it's usually there for some
other purpose.

> but this seems to be the cleanest way despite that.  Let's follow the
> philosophy of builing from small building blocks for our kernel APIs aswell.

I'm not so sure of that.  Currently the rest of the kernel is unaware there's a
timer there and doesn't have to do anything about it directly.

> As a second benefit it also makes handling the case of having both delayed
> and immediate items on a single workqueue trivial.

It's pretty straightforward as it is now.  The worst bit is that we have to
have several functions that do the same or a similar thing but with different
names because they take different arguments.

The benefit of what we have at the moment is that there is only one timer
callback routine required and everything uses that - not that we can't just
export that, but it's cleaner to set things up since the rest of the kernel
doesn't know there's a timer involved.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ