linux-kernel - Re: [PATCH] x86/paravirt: revert exports to restore old behaviour

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Nov 2007 23:39:09 +0100
From:	Adrian Bunk <bunk@...nel.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tobias Powalowski <t.powa@....de>,
	Takashi Iwai <tiwai@...e.de>,
	Christoph Hellwig <hch@...radead.org>,
	Zachary Amsden <zach@...are.com>
Subject: Re: [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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/