lkml.org 
[lkml]   [2007]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86/paravirt: revert exports to restore old behaviour
On Wed, Nov 28, 2007 at 01:15:39PM -0800, Jeremy Fitzhardinge wrote:
> Adrian Bunk wrote:
> > On Tue, Nov 27, 2007 at 02:57:30PM -0800, Jeremy Fitzhardinge wrote:
>...
> >> 2. It's a regression from previous kernels, which would work these
> >> modules even with CONFIG_PARAVIRT enabled.
> >> ...
> >>
> >
> > It cannot be a regression since the kernel does not have a stable API
> > for modules.
> >
>
> Anything that once worked but now does not is a regression. Generally
> when we intend a regression like this, we call it a deprecation of an
> interface and have a procedure for that. It was not my intention to
> cause a regression with this change, and an unintended regression is a bug.

The standard procdure for changing the in-kernel API is to simply break
the API without any deprecation or advance notice.

Andrew has some strange views that big changes can be done immediately
while smaller changes should require deprecation periods, but everyone
else seems to have less strange views.

> >> Therefore, I think this patch should go in for 2.6.24. If people
> >> really think that these operations should not be available to modules,
> >> then we can address that separately.
> >> ...
> >>
> >
> > Why should we start with one step back for getting two steps ahead?
>
> Why is it a step back? What are the steps ahead? There's been no
> discussion on this point, so I don't think you can assume there's a
> clear way forward.
>
> I think Linus and Andrew have been pretty clear on the policy for these
> kinds of things: regressions are always bad, even if fixing the
> regression means some other bugfix needs to be put off.

This does not apply since we do not have a stable in-kernel API, and
therefore changes to the in-kernel API can by definition not be
regressions.

2.6.24 most likely contains hundreds of changes and removals of
in-kernel APIs that existed in 2.6.23.

Are you seriously suggesting that e.g. every single change to any struct
under include/ [1] would require an announcement x kernel releases
before it can be implemented?

And yes, things like that would be required if we offered any kind of
API stability.

> J

cu
Adrian

[1] even additions would be problematic since buggy external modules
might have hardcoded the struct size somewhere...

--

"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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-11-28 23:41    [W:0.054 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site