On Thu, May 25, 2006 at 03:56:24PM +1000, Nick Piggin wrote:
> >+#include <linux/writeback.h>
> >+#include <linux/nfsd/const.h>
> >
>
> How come you're adding these includes?
For something added in the past and removed later...
> >+#define PAGES_BYTE(size) (((size) + PAGE_CACHE_SIZE - 1) >>
> >PAGE_CACHE_SHIFT)
> >+#define PAGES_KB(size) PAGES_BYTE((size)*1024)
> >
> Don't really like the names. Don't think they do anything for clarity, but
> if you can come up with something better for PAGES_BYTE I might change my
> mind ;) (just forget about PAGES_KB - people know what *1024 means)
No, they are mainly for concision. Don't you think it's cleaner to write
PAGES_KB(VM_MAX_READAHEAD)
than
(VM_MAX_READAHEAD * 1024) / PAGE_CACHE_SIZE
Admittedly the names are somewhat awkward though :)
> Also: the replacements are wrong: if you've defined VM_MAX_READAHEAD to be
> 4095 bytes, you don't want the _actual_ readahead to be 4096 bytes, do you?
> It is saying nothing about minimum, so presumably 0 is the correct choice.
The macros were first introduced exact for this reason ;)
It is rumored that there will be 64K page support, and this macro
helps round up the 16K sized VM_MIN_READAHEAD. The eof_index also
needs rounding up.
> >+#define next_page(pg) (list_entry((pg)->lru.prev, struct page, lru))
> >+#define prev_page(pg) (list_entry((pg)->lru.next, struct page, lru))
> >
>
> Again, it is probably easier just to use the expanded version. Then the
> reader can immediately say: ah, the next page on the LRU list (rather
> than, maybe, the next page in the pagecache).
Ok, will expand it.
Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
