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:	Thu, 14 Feb 2008 01:58:43 +0200
From:	Adrian Bunk <bunk@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	harvey.harrison@...il.com, torvalds@...ux-foundation.org,
	davem@...emloft.net, tglx@...utronix.de, hpa@...or.com,
	xemul@...nvz.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] feature-removal: add documentation for exported
	symbols going away

On Wed, Feb 13, 2008 at 03:43:31PM -0800, Andrew Morton wrote:
> On Thu, 14 Feb 2008 01:22:48 +0200
> Adrian Bunk <bunk@...nel.org> wrote:
> 
> > I don't get your point why bigger API changes should still be allowed 
> > without any advance warning while removing an export should require 
> > deprecation periods.
> 
> Because the cost to us of giving people a few months warning is miniscule,
> and doing so a) is courteous to our users and b) possibly avoids driving
> away testers.

The miniscule cost is my spare time and my nerves.

These unexport discussions are _the_ thing that have turned kernel 
development from having been fun into creating anger for me. If your 
goal is to bring me to quitting kernel development and spending my spare 
time differently you've already gotten quite near to reaching your goal.

> otoh the cost to us of avoiding large API changes is much much higher, so
> the tradeoff has a different outcome.
> 
> > If you want to offer a stable API for external modules then please do 
> > it completely and with all consequences.
> 
> Sorry, but you have this belief that if we do X in one case then we should
> rigorously do X in all cases.  That everything we do sets precedents which
> must be forever and in all cases followed.  That it is all about rules and
> sticking to them.  That if you can catch person A taking action B then you
> can trap that person into doing B in all cases for ever more.
> 
> Well it doesn't work like that.  Each case is different and each case has
> pros and cons and each one needs to be weighed according to those pros and
> cons.

Unexports are done immediately when there's a subsystem maintainer 
taking a patch and deprecation periods are required when a patch has to 
go through you...

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

--
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/

Powered by blists - more mailing lists