On 13-02-08 23:22, Harvey Harrison wrote:
+---
+
+What: io_delay_type
+Where: arch/x86/kernel/io_delay.c
+When: 2.6.28
+Why: No in tree users
The entirety of io_delay.c should be gone long before .28. It's a short term
thing till the port 0x80 problems have been
On 13-02-08 23:22, Harvey Harrison wrote:
+---
+
+What: io_delay_type
+Where: arch/x86/kernel/io_delay.c
+When: 2.6.28
+Why: No in tree users
The entirety of io_delay.c should be gone long before .28. It's a short term
thing till the port 0x80 problems have been
> 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...
Agreed - with the expect of stuff which is used in tree or forms part of
a logical exported API we should just throw them out
On Wed, Feb 13, 2008 at 03:43:31PM -0800, Andrew Morton wrote:
> On Thu, 14 Feb 2008 01:22:48 +0200
> Adrian Bunk <[EMAIL PROTECTED]> 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
> >
On Thu, 14 Feb 2008 01:22:48 +0200
Adrian Bunk <[EMAIL PROTECTED]> 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
On Wed, Feb 13, 2008 at 02:54:05PM -0800, Andrew Morton wrote:
> On Thu, 14 Feb 2008 00:43:08 +0200
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > There's simply no point in treating the removal of exports differently
> > from the many other API breaks we have in each release.
>
> I have
On Wed, 13 Feb 2008 14:22:06 -0800
Harvey Harrison <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
> ---
> Documentation/feature-removal-schedule.txt | 10 --
> Documentation/feature-removal/exported-symbols.txt | 34
>
>
On Wed, Feb 13, 2008 at 02:42:30PM -0800, Harvey Harrison wrote:
> On Thu, 2008-02-14 at 00:34 +0200, Adrian Bunk wrote:
> > On Wed, Feb 13, 2008 at 02:22:06PM -0800, Harvey Harrison wrote:
> > > +
> > > +What:__inet_hash_connect
> > > +Where: net/ipv4/inet_hashtables.c
> > > +When:
On Thu, 14 Feb 2008 00:43:08 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> There's simply no point in treating the removal of exports differently
> from the many other API breaks we have in each release.
I have repeatedly and relatively patiently explained to you what the
point is. Simply
On Thu, 2008-02-14 at 00:34 +0200, Adrian Bunk wrote:
> On Wed, Feb 13, 2008 at 02:22:06PM -0800, Harvey Harrison wrote:
> > +
> > +What: __inet_hash_connect
> > +Where: net/ipv4/inet_hashtables.c
> > +When: 2.6.28
> > +Why: No in tree users
> > +
> >
BTW:
Sorry and it's not your fault if my answer was a bit harsh.
Your patch forces a nonsense that until now only Andrew tried to enforce
(which BTW made me avoiding him whenever possible and never looking at
-mm anymore).
There's simply no point in treating the removal of exports differently
On Wed, Feb 13, 2008 at 02:22:06PM -0800, Harvey Harrison wrote:
>...
> --- /dev/null
> +++ b/Documentation/feature-removal/exported-symbols.txt
> @@ -0,0 +1,34 @@
> +The following is a list of symbols whose exports are unused in the kernel
> +tree and will be removed. Unused symbols are both
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Documentation/feature-removal-schedule.txt | 10 --
Documentation/feature-removal/exported-symbols.txt | 34
arch/x86/kernel/io_delay.c |2 +-
net/ipv4/inet_hashtables.c
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
Documentation/feature-removal-schedule.txt | 10 --
Documentation/feature-removal/exported-symbols.txt | 34
arch/x86/kernel/io_delay.c |2 +-
net/ipv4/inet_hashtables.c
On Wed, Feb 13, 2008 at 02:42:30PM -0800, Harvey Harrison wrote:
On Thu, 2008-02-14 at 00:34 +0200, Adrian Bunk wrote:
On Wed, Feb 13, 2008 at 02:22:06PM -0800, Harvey Harrison wrote:
+
+What:__inet_hash_connect
+Where: net/ipv4/inet_hashtables.c
+When:2.6.28
+Why:
On Wed, Feb 13, 2008 at 02:22:06PM -0800, Harvey Harrison wrote:
...
--- /dev/null
+++ b/Documentation/feature-removal/exported-symbols.txt
@@ -0,0 +1,34 @@
+The following is a list of symbols whose exports are unused in the kernel
+tree and will be removed. Unused symbols are both
On Thu, 2008-02-14 at 00:34 +0200, Adrian Bunk wrote:
On Wed, Feb 13, 2008 at 02:22:06PM -0800, Harvey Harrison wrote:
+
+What: __inet_hash_connect
+Where: net/ipv4/inet_hashtables.c
+When: 2.6.28
+Why: No in tree users
+
+---
+
+What:
BTW:
Sorry and it's not your fault if my answer was a bit harsh.
Your patch forces a nonsense that until now only Andrew tried to enforce
(which BTW made me avoiding him whenever possible and never looking at
-mm anymore).
There's simply no point in treating the removal of exports differently
On Thu, 14 Feb 2008 00:43:08 +0200
Adrian Bunk [EMAIL PROTECTED] wrote:
There's simply no point in treating the removal of exports differently
from the many other API breaks we have in each release.
I have repeatedly and relatively patiently explained to you what the
point is. Simply saying
On Wed, 13 Feb 2008 14:22:06 -0800
Harvey Harrison [EMAIL PROTECTED] wrote:
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
Documentation/feature-removal-schedule.txt | 10 --
Documentation/feature-removal/exported-symbols.txt | 34
On Wed, Feb 13, 2008 at 02:54:05PM -0800, Andrew Morton wrote:
On Thu, 14 Feb 2008 00:43:08 +0200
Adrian Bunk [EMAIL PROTECTED] wrote:
There's simply no point in treating the removal of exports differently
from the many other API breaks we have in each release.
I have repeatedly and
On Thu, 14 Feb 2008 01:22:48 +0200
Adrian Bunk [EMAIL PROTECTED] 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
On Wed, Feb 13, 2008 at 03:43:31PM -0800, Andrew Morton wrote:
On Thu, 14 Feb 2008 01:22:48 +0200
Adrian Bunk [EMAIL PROTECTED] 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
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...
Agreed - with the expect of stuff which is used in tree or forms part of
a logical exported API we should just throw them out without
24 matches
Mail list logo
