Re: [PATCH] SLOW_WORK: Fix the CONFIG_MODULES=n case

David Howells <[email protected]>
Newsgroups gmane.linux.file-systems.cachefs.general,gmane.linux.cluster.redhat.cluster.devel,gmane.linux.nfsv4,gmane.linux.kernel,gmane.linux.file-systems,gmane.linux.file-systems.cifs
Organization Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903
Message-ID <[email protected]>
Ingo Molnar <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.