Linus, Andrew, Christoph,
There are 29 listed items in feature-removal-schedule.txt. 11 of those have
dates or kernel versions that have passed, including this one:
What: remove EXPORT_SYMBOL(kernel_thread)
When: August 2006
One feature (removal of sys_sysctl) is listed for September 2010: are we
really able to predict the future with this much accuracy?
When, if at all, will those future/overdue features be removed for real?
Have any of them been removed already? It's very important to developers to
have more accurate removal schedule for planning purposes.
I think setting dates on feature removal isn't compatible with the current
model of kernel code development, b/c despite our best efforts, it's hard to
predict the precise release of the next 2.6.(x+1) kernel. I think it's
better to change all of those dates to future kernel versions (a couple of
items do so). When those dates were assigned, was there a specific kernel
version in mind?
Thanks,
Erez.
On Mon, 3 Dec 2007 11:58:07 -0500
Erez Zadok <[email protected]> wrote:
> Linus, Andrew, Christoph,
>
> There are 29 listed items in feature-removal-schedule.txt. 11 of those have
> dates or kernel versions that have passed, including this one:
>
> What: remove EXPORT_SYMBOL(kernel_thread)
> When: August 2006
That means they were proposed a long time ago and people were given
plenty of time to stop using them.
>
> One feature (removal of sys_sysctl) is listed for September 2010: are we
> really able to predict the future with this much accuracy?
The sysctl one is fantasy - its a kernel/user ABI so isn't going to be
going anywhere in a hurry.
On Dec 3 2007 11:58, Erez Zadok wrote:
>
>What: remove EXPORT_SYMBOL(kernel_thread)
>When: August 2006
>
>One feature (removal of sys_sysctl) is listed for September 2010: are we
>really able to predict the future with this much accuracy?
>
>When, if at all, will those future/overdue features be removed for real?
>Have any of them been removed already? It's very important to developers to
>have more accurate removal schedule for planning purposes.
>
>I think setting dates on feature removal isn't compatible with the current
>model of kernel code development, b/c despite our best efforts, it's hard to
>predict the precise release of the next 2.6.(x+1) kernel.
The release dates of Linux kernels are much more deterministic than
the removal dates in feature-removal-schedule.txt are accurate.
The reason I see for this is that many list readers do not object
patches that extend frs.txt, but there is always 'a lot' of
resistance when actually attempting to remove code. raw.ko is
probably the best example.
This kinda defeats the purpose of frs.txt. If subsys maintainers do
not croak when they see patches that add to frs.txt (assuming the
maintainers see the patches, to be fair), I take it they agree to
removing the feature soon. If not, the textfile should probably be
renamed to features-we-would-like-to-get-rid-of-sooner-or-later.txt.
On Mon, Dec 03, 2007 at 11:58:07AM -0500, Erez Zadok wrote:
> There are 29 listed items in feature-removal-schedule.txt. 11 of those have
> dates or kernel versions that have passed, including this one:
>
> What: remove EXPORT_SYMBOL(kernel_thread)
> When: August 2006
We still haven't managed to kill all intree modular users of this.
I'll be gone as soon as that happens. It might be worth updating the
file to idicate exactly that.