On Sun, 15 Jan 2012, Jesper Juhl wrote:
> > > -/* This code will be removed after deprecation time exceeded (2.6.41) */
> > > +/* This code will be removed after deprecation time exceeded (3.1) */
> >
> > Shouldn't the real fix be to remove this code? What's the use of
> > changing the version number that this code will be removed from, when
> > the change won't get in until after the version that this code should
> > have been removed?
> >
> > This is like updating 2014 calendars to say the world will end in 2012.
> >
> Heh, yeah, in a way you are right. But we have lots of code in the kernel
> that says it will be removed at <some date in the past>, so I just figured
> that if this code ends up hanging around it should at least display the
> correct version number for when it /should/ have been removed.
> The actual removal I'll leave up to others.
Funny thing. Okay, this doesn't seem to be in linux-next, so I am taking
it.
Steven, planning to drop the code in a near future? :)
--
Jiri Kosina
SUSE Labs
On 2/3/2012 1:42 PM, Jiri Kosina wrote:
> On Sun, 15 Jan 2012, Jesper Juhl wrote:
>
>>>> -/* This code will be removed after deprecation time exceeded (2.6.41) */
>>>> +/* This code will be removed after deprecation time exceeded (3.1) */
>>>
>>> Shouldn't the real fix be to remove this code? What's the use of
>>> changing the version number that this code will be removed from, when
>>> the change won't get in until after the version that this code should
>>> have been removed?
>>>
>>> This is like updating 2014 calendars to say the world will end in 2012.
>>>
>> Heh, yeah, in a way you are right. But we have lots of code in the kernel
>> that says it will be removed at <some date in the past>, so I just figured
>> that if this code ends up hanging around it should at least display the
>> correct version number for when it /should/ have been removed.
>> The actual removal I'll leave up to others.
>
> Funny thing. Okay, this doesn't seem to be in linux-next, so I am taking
> it.
>
> Steven, planning to drop the code in a near future? :)
we shouldn't be dropping these yet.. tools are still using them.
and there really is no cost to keeping them either.
On Fri, 2012-02-03 at 13:51 -0800, Arjan van de Ven wrote:
> On 2/3/2012 1:42 PM, Jiri Kosina wrote:
> > On Sun, 15 Jan 2012, Jesper Juhl wrote:
> >
> >>>> -/* This code will be removed after deprecation time exceeded (2.6.41) */
> >>>> +/* This code will be removed after deprecation time exceeded (3.1) */
> >>>
> >>> Shouldn't the real fix be to remove this code? What's the use of
> >>> changing the version number that this code will be removed from, when
> >>> the change won't get in until after the version that this code should
> >>> have been removed?
> >>>
> >>> This is like updating 2014 calendars to say the world will end in 2012.
> >>>
> >> Heh, yeah, in a way you are right. But we have lots of code in the kernel
> >> that says it will be removed at <some date in the past>, so I just figured
> >> that if this code ends up hanging around it should at least display the
> >> correct version number for when it /should/ have been removed.
> >> The actual removal I'll leave up to others.
> >
> > Funny thing. Okay, this doesn't seem to be in linux-next, so I am taking
> > it.
> >
> > Steven, planning to drop the code in a near future? :)
>
> we shouldn't be dropping these yet.. tools are still using them.
> and there really is no cost to keeping them either.
Then the correct fix is to remove the comment, as it is incorrect.
-- Steve
On Sat, 4 Feb 2012, Steven Rostedt wrote:
> On Fri, 2012-02-03 at 13:51 -0800, Arjan van de Ven wrote:
> > On 2/3/2012 1:42 PM, Jiri Kosina wrote:
> > > On Sun, 15 Jan 2012, Jesper Juhl wrote:
> > >
> > >>>> -/* This code will be removed after deprecation time exceeded (2.6.41) */
> > >>>> +/* This code will be removed after deprecation time exceeded (3.1) */
> > >>>
> > >>> Shouldn't the real fix be to remove this code? What's the use of
> > >>> changing the version number that this code will be removed from, when
> > >>> the change won't get in until after the version that this code should
> > >>> have been removed?
> > >>>
> > >>> This is like updating 2014 calendars to say the world will end in 2012.
> > >>>
> > >> Heh, yeah, in a way you are right. But we have lots of code in the kernel
> > >> that says it will be removed at <some date in the past>, so I just figured
> > >> that if this code ends up hanging around it should at least display the
> > >> correct version number for when it /should/ have been removed.
> > >> The actual removal I'll leave up to others.
> > >
> > > Funny thing. Okay, this doesn't seem to be in linux-next, so I am taking
> > > it.
> > >
> > > Steven, planning to drop the code in a near future? :)
> >
> > we shouldn't be dropping these yet.. tools are still using them.
> > and there really is no cost to keeping them either.
>
> Then the correct fix is to remove the comment, as it is incorrect.
From: Jesper Juhl <[email protected]>
Date: Sat, 4 Feb 2012 23:29:19 +0100
Subject: [PATCH] Remove incorrect comment from include/trace/events/power.h
The code is not going to be removed, so remove the comment stating
that it will be.
Signed-off-by: Jesper Juhl <[email protected]>
---
include/trace/events/power.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 1bcc2a8..5800eb8 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -65,7 +65,6 @@ TRACE_EVENT(machine_suspend,
TP_printk("state=%lu", (unsigned long)__entry->state)
);
-/* This code will be removed after deprecation time exceeded (2.6.41) */
#ifdef CONFIG_EVENT_POWER_TRACING_DEPRECATED
/*
--
1.7.9
--
Jesper Juhl <[email protected]> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
On Sat, 2012-02-04 at 23:31 +0100, Jesper Juhl wrote:
> From: Jesper Juhl <[email protected]>
> Date: Sat, 4 Feb 2012 23:29:19 +0100
> Subject: [PATCH] Remove incorrect comment from include/trace/events/power.h
>
> The code is not going to be removed, so remove the comment stating
> that it will be.
>
> Signed-off-by: Jesper Juhl <[email protected]>
Acked-by: Steven Rostedt <[email protected]>
-- Steve
> ---
> include/trace/events/power.h | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/include/trace/events/power.h b/include/trace/events/power.h
> index 1bcc2a8..5800eb8 100644
> --- a/include/trace/events/power.h
> +++ b/include/trace/events/power.h
> @@ -65,7 +65,6 @@ TRACE_EVENT(machine_suspend,
> TP_printk("state=%lu", (unsigned long)__entry->state)
> );
>
> -/* This code will be removed after deprecation time exceeded (2.6.41) */
> #ifdef CONFIG_EVENT_POWER_TRACING_DEPRECATED
>
> /*
> --
> 1.7.9
>
>
>