Re: [PATCH 04/16] GFS2: Daemons and address space operations

[Jan Engelhardt <jengelh@linux01.gwdg.de>]

>> >+	offset += (2*sizeof(__be64) - 1);
>> 
>> >+#ifndef __LOPS_DOT_H__
>> >+#define __LOPS_DOT_H__
>> 
>> +struct gfs2_log_operations;
>> 
>> Making sure every .h file would "compile" on its own, this also means #include
>> <linux/list.h> for the below, f.ex..
>> 
>Is this really a requirement? I suspect there are a fair few exception
>to this over the kernel code.

A requirement - not yet. I could not find my own post about it, but this 
one is a similar one two years earlier http://lkml.org/lkml/2004/6/15/90

>> Maybe there should be at least one humna person listen in AUTHOR.
>> 
>Ok, I'll get back to you on that one :-)

Should have been "human" of course.

>Are you saying that they should all end in a , or that they should not,
>or even just that it should be consistent?

There seems to be no explicit CodingStyle rule at this point, so you are 
free to choose either. Just be consistent (like with the goto labels).

>> >+++ b/fs/gfs2/ops_address.c
>> >+	if (likely(file != &gfs2_internal_file_sentinal)) {
>> 
>> The thing is usually called "sentinel". Alan might prove me wrong that both
>> spelling variants are possible :-)
>> 
>I think you are right, so I've changed it.

http://dictionary.reference.com/search?q=sentinal&x=0&y=0
W.W.W.W.W.

>> >+static void stuck_releasepage(struct buffer_head *bh)
>> >+{
>> >+static unsigned limit = 0;
>> 
>> Is this really ok to have?
>> 
>I think so. I don't really care about the odd race here. All I want to
>do is ensure that in the (very unlikely, I hope) situation of this
>function being called, we don't land up generating huge amounts of
>debugging information. Usually only the first message will have the

There is printk_ratelimit() and SUBSYSTEM_ratelimit().

>useful information in it, so this was just to ensure that we are not
>flooded. I have made a slight change to it though. Let me know if you'd
>like some further changes in this area.


Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/