
Messages in this thread
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.



"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-09-10 22:01    [from the cache]
©2003-2011 Jasper Spaans