[2.6 patch] unexport install_page

[2.6 patch] unexport install_page

[Adrian Bunk]

No in-kernel module is using it, so there's no reason bloating the 
kernel with this EXPORT_SYMBOL.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.16-rc3-mm1-full/mm/fremap.c.old	2006-02-16 16:45:09.000000000 +0100
+++ linux-2.6.16-rc3-mm1-full/mm/fremap.c	2006-02-16 16:45:18.000000000 +0100
@@ -89,7 +89,6 @@
 out:
 	return err;
 }
-EXPORT_SYMBOL(install_page);
 
 /*
  * Install a file pte to a given virtual memory address, release any

[2.6 patch] unexport install_page

[Adrian Bunk]

No in-kernel module is using it, so there's no reason bloating the 
kernel with this EXPORT_SYMBOL.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 16 Feb 2006

--- linux-2.6.16-rc3-mm1-full/mm/fremap.c.old	2006-02-16 16:45:09.000000000 +0100
+++ linux-2.6.16-rc3-mm1-full/mm/fremap.c	2006-02-16 16:45:18.000000000 +0100
@@ -89,7 +89,6 @@
 out:
 	return err;
 }
-EXPORT_SYMBOL(install_page);
 
 /*
  * Install a file pte to a given virtual memory address, release any

Re: [2.6 patch] unexport install_page

[Christoph Hellwig]

On Mon, Feb 20, 2006 at 11:37:09PM +0100, Adrian Bunk wrote:
> No in-kernel module is using it, so there's no reason bloating the 
> kernel with this EXPORT_SYMBOL.

And no one should be using it, really.  It's a helper for sys_remap_file_pages
implementations, something that nothing but the generic filemap.c or
shmem.c should do.

Re: [2.6 patch] unexport install_page

[Hugh Dickins]

On Tue, 21 Feb 2006, Christoph Hellwig wrote:
> On Mon, Feb 20, 2006 at 11:37:09PM +0100, Adrian Bunk wrote:
> > No in-kernel module is using it, so there's no reason bloating the 
> > kernel with this EXPORT_SYMBOL.
> 
> And no one should be using it, really.

Why's that?

> It's a helper for sys_remap_file_pages implementations,

Exactly (to support non-linear vmas and MAP_POPULATE).

> something that nothing but the generic filemap.c or shmem.c should do.

Why's that?  It's rightly been recognized as a library function since
2.6.0-test3.  I'd say it should remain exported for whatever filesystems
might wish to use it (but no, I've no vested interest, the filesystem
you'll suspect me of arguing for does not use it ;)

<akpm@osdl.org>
  [PATCH] export install_page() to modules

  install_page() is a library function which we expect will be used by all
  drivers which implement vm_operations.populate().  Therefore it should be
  exported to kernel modules.

  Petr Vandrovec has a project which involves sparse mappings of device memory
  which can use remap_file_pages().  It needs install_page().
  
Hugh

Re: [2.6 patch] unexport install_page

[Adrian Bunk]

On Tue, Feb 21, 2006 at 12:49:51PM +0000, Hugh Dickins wrote:
>...
> Why's that?  It's rightly been recognized as a library function since
> 2.6.0-test3.  I'd say it should remain exported for whatever filesystems
> might wish to use it (but no, I've no vested interest, the filesystem
> you'll suspect me of arguing for does not use it ;)
> 
> <akpm@osdl.org>
>   [PATCH] export install_page() to modules
> 
>   install_page() is a library function which we expect will be used by all
>   drivers which implement vm_operations.populate().  Therefore it should be
>   exported to kernel modules.
> 
>   Petr Vandrovec has a project which involves sparse mappings of device memory
>   which can use remap_file_pages().  It needs install_page().


This export was justified in mid-2003 with a projet that would use it.

Now it's 2006, and there's still no in-kernel user.

This means it has only bloated the kernel for two and a half years 
for nearly everyone.


> Hugh

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] unexport install_page

[Alan Cox]

On Maw, 2006-02-21 at 15:13 +0100, Adrian Bunk wrote:
> This means it has only bloated the kernel for two and a half years 
> for nearly everyone.

Wouldn't it be more productive to just shave 30 bytes off some other
function and make it faster instead of moaning about every single export
symbol that is provided even when its intentionally part of a complete
API ?

Re: [2.6 patch] unexport install_page

[Adrian Bunk]

On Tue, Feb 21, 2006 at 02:34:33PM +0000, Alan Cox wrote:
> On Maw, 2006-02-21 at 15:13 +0100, Adrian Bunk wrote:
> > This means it has only bloated the kernel for two and a half years 
> > for nearly everyone.
> 
> Wouldn't it be more productive to just shave 30 bytes off some other
> function and make it faster instead of moaning about every single export
> symbol that is provided even when its intentionally part of a complete
> API ?

Wouldn't it be best to do both?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[2.6 patch] unexport install_page

[Adrian Bunk]

No in-kernel module is using it, so there's no reason bloating the 
kernel with this EXPORT_SYMBOL.

The addition was justified back in 2003 with being required for a 
project, but it's still not used by any in-kernel module.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 20 Feb 2006
- 16 Feb 2006

--- linux-2.6.16-rc3-mm1-full/mm/fremap.c.old	2006-02-16 16:45:09.000000000 +0100
+++ linux-2.6.16-rc3-mm1-full/mm/fremap.c	2006-02-16 16:45:18.000000000 +0100
@@ -89,7 +89,6 @@
 out:
 	return err;
 }
-EXPORT_SYMBOL(install_page);
 
 /*
  * Install a file pte to a given virtual memory address, release any