Re: [-mm patch] unexport sys_{open,read}

[Adrian Bunk <bunk@kernel.org>]

On Mon, Sep 10, 2007 at 10:25:56AM -0700, Andrew Morton wrote:
>...
> Also, Adrian goes on and on with weird theories about how I'm picking on
> him.  But other patches (such as 7d12e780e003f93433d49ce78c) DO OTHER
> STUFF.  Like simplify the code, and make it smaller, faster or more
> maintainable or more reliable.

The unexport of sys_{open,read} actually makes the kernel smaller...

> So the tradeoff is quite different from a
> one-liner which does nothing but kill an export.  And, contrary to his
> claims, we _do_ put temporary back-compat wrappers in there when we
> change interfaces on those relatively rare occasions when it is possible,
> and when we remember to do it.

Your tradeoff misses the impact on external modules.

The unexport of sys_open will not break many modules, while
commit 7d12e780e003f93433d49ce78c most likely broke the majority of 
external modules.

Do we guarantee some API stability to module authors or do we not 
guarantee this?

Emphasizing on API stability in the cases that don't matter much while 
breaking the API in cases that affect most modules doesn't make any 
sense at all.

And your "remember to do it" is an important point. As an example, every 
change to a struct that is part of the signature of one or exportted 
functions does change the API of all of these functions. If we offer any 
API stability for external modules we need to review all patches that 
touch include/ because many of them contain changes to the modules API 
that might otherwise get missed.

Let's either continue to state that their is no stable API for external 
modules or define some API stability rules and do whatever is required 
for implementing them.

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