Messages in this thread | | | Date | Tue, 22 Dec 2015 03:10:14 +0000 | From | Al Viro <> | Subject | Re: [RFC] free_pages stuff |
| |
On Mon, Dec 21, 2015 at 05:23:11PM -0800, Linus Torvalds wrote:
> And if the code really explicitly wants a page (or set of aligned > pages) for some vm reason, I suspect having the cast there isn't a bad > thing. It's clearly not just a random pointer allocation if the bit > pattern of the pointer matters. > > And yes, most of the people who used to want "unsigned long" have long > since been converted to take "struct page *" instead, since things > like the VM wants highmem pages etc. There's a reason why the > historical interface returns "unsigned long": it _used_ to be the > right thing for a lot of code. The fact that there now are more casts > than not are about changing use patterns, but I don't think that means > that we should change the calling convention that has a historical > reason for it.
Umm... Depends on how early you look. In 0.01: fs/exec.c:179: if (!(page[i]=get_free_page())) fs/inode.c:208: if (!(inode->i_size=get_free_page())) { kernel/fork.c:70: p = (struct task_struct *) get_free_page(); mm/memory.c:143: if (!(to_page_table = (unsigned long *) get_free_page())) mm/memory.c:185: if (!(tmp=get_free_page())) mm/memory.c:203: if (!(new_page=get_free_page())) mm/memory.c:241: if (tmp=get_free_page())
the last 3 are "we want struct page *" variety, the rest is "want a pointer" stuff (exec.c one is copy_strings() and the only use of pages[...] is a cast to char *, inode.c one is get_pipe_inode() - I guess you didn't want to bother with adding pipe-specific fields to struct inode at that point and since ->i_size is unused for pipes anyway reused it to keep a pointer to pipe buffer). Even then it wasn't the majority.
By 2.0 (still before highmem) the fraction was already _way_ below 50%...
| |