All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: dhowells@redhat.com, torvalds@osdl.org,
	akpm@linux-foundation.org, steved@redhat.com,
	jens.axboe@oracle.com, linux-cachefs@redhat.com,
	nfsv4@linux-nfs.org, linux-fsdevel@vger.kernel.org,
	cluster-devel@redhat.com, linux-kernel@vger.kernel.org,
	linux-cifs-client@lists.samba.org
Subject: Re: [PATCH] SLOW_WORK: Fix the CONFIG_MODULES=n case
Date: Tue, 01 Dec 2009 15:13:08 +0000	[thread overview]
Message-ID: <31860.1259680388@redhat.com> (raw)
In-Reply-To: <20091201142611.GA1183@elte.hu>

Ingo Molnar <mingo@elte.hu> wrote:

> this slow_work_wait_for_items() function should move into the #ifdef 
> block too.

I disagree: I want to keep the variable declaration blocks small; I'd rather
not even put the inline functions in there that I did.  I only did that because
you wanted the #ifdef count reduced.

> In terms of .32 i guess it's OK too and the fix is needed - but i'd really
> not have done even the preceding changes - why again did we need
> /proc/slow_work_rq via 8fba10a

The slow_work_rq debugging interface is not strictly necessary, but it proved a
useful debugging tool.  I emailed Linus before I went on holiday and asked if
he was willing to take these not-strictly-necessary patches on which other
patches were built, or whether he'd prefer me to drop those patches and adjust
the rest.

> and why did it have to happen right before the final kernel?

Because it did.  That's when I finished my set of patches and published them
before going on holiday for a week - and that in turn was related to when I
came up with a better test case.  Sometimes coincidences do happen.

> If then it should have been done in debugfs - we dont need yet another 
> /proc ABI.

Possibly.  That just means we have a debugfs ABI instead of a proc ABI - it
needs maintaining either way.  On the other hand, it can be moved there easily
and the docs changed, and doing so makes a reasonable amount of sense - except
that debugfs isn't normally mounted by at least Fedora for some reason.

David

WARNING: multiple messages have this Message-ID (diff)
From: David Howells <dhowells@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: cluster-devel@redhat.com, nfsv4@linux-nfs.org,
	linux-kernel@vger.kernel.org, torvalds@osdl.org,
	linux-cachefs@redhat.com, jens.axboe@oracle.com,
	linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org,
	linux-cifs-client@lists.samba.org
Subject: Re: [PATCH] SLOW_WORK: Fix the CONFIG_MODULES=n case
Date: Tue, 01 Dec 2009 15:13:08 +0000	[thread overview]
Message-ID: <31860.1259680388@redhat.com> (raw)
In-Reply-To: <20091201142611.GA1183@elte.hu>

Ingo Molnar <mingo@elte.hu> wrote:

> this slow_work_wait_for_items() function should move into the #ifdef 
> block too.

I disagree: I want to keep the variable declaration blocks small; I'd rather
not even put the inline functions in there that I did.  I only did that because
you wanted the #ifdef count reduced.

> In terms of .32 i guess it's OK too and the fix is needed - but i'd really
> not have done even the preceding changes - why again did we need
> /proc/slow_work_rq via 8fba10a

The slow_work_rq debugging interface is not strictly necessary, but it proved a
useful debugging tool.  I emailed Linus before I went on holiday and asked if
he was willing to take these not-strictly-necessary patches on which other
patches were built, or whether he'd prefer me to drop those patches and adjust
the rest.

> and why did it have to happen right before the final kernel?

Because it did.  That's when I finished my set of patches and published them
before going on holiday for a week - and that in turn was related to when I
came up with a better test case.  Sometimes coincidences do happen.

> If then it should have been done in debugfs - we dont need yet another 
> /proc ABI.

Possibly.  That just means we have a debugfs ABI instead of a proc ABI - it
needs maintaining either way.  On the other hand, it can be moved there easily
and the docs changed, and doing so makes a reasonable amount of sense - except
that debugfs isn't normally mounted by at least Fedora for some reason.

David

  reply	other threads:[~2009-12-01 15:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-01 13:52 [PATCH] SLOW_WORK: Fix the CONFIG_MODULES=n case David Howells
2009-12-01 13:52 ` David Howells
2009-12-01 14:26 ` Ingo Molnar
2009-12-01 14:26   ` Ingo Molnar
2009-12-01 15:13   ` David Howells [this message]
2009-12-01 15:13     ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=31860.1259680388@redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cluster-devel@redhat.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-cifs-client@lists.samba.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nfsv4@linux-nfs.org \
    --cc=steved@redhat.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.