Re: other potential candidates for removal?

["Robert P. J. Day" <rpjday@mindspring.com>]

On Wed, 18 Jul 2007, Jesper Juhl wrote:

> On 18/07/07, Robert P. J. Day <rpjday@mindspring.com> wrote:
> >
> >    a while back, i threw together this wiki page:
> >
> > http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
> >
> > feel free to comment.
> >
> Some comments on that list :
>
> } PCMCIA IOCTL support
> }
> } Currently listed in the removal file as scheduled for deletion back
> in November of 2005, but
> } there's some debate as to whether it's really ready to go.
>
> If you remove that don't you run the risk of breaking existing
> userspace (something which we don't do lightly) ?

sure but, once again, if that's the case, why is it still listed for
(long overdue) removal?  you could make the above argument for every
single feature in the removal file, and never be able to remove
*anything*.

> Same goes for other IOCTL's on the list as well as the ulog support.

i should point out that some of the content of that wiki page was
extracted from the Kconfig files themselves, where those features were
explicitly listed as obsolete.  from net/bridge/netfilter/Kconfig:

...
config BRIDGE_EBT_ULOG
        tristate "ebt: ulog support (OBSOLETE)"
...

in addition, note my comment on the wiki page -- that the help info
for that option even *mentions* that it's been obsoleted by a newer
feature.

> Also, some items seem to have made the list since they depend on
> BROKEN_ON_SMP or have no active maintainer.  As for depending on
> BROKEN_ON_SMP, as long as the drivers work fine on UP they may have
> users, so removing them would constitute regressions for those users
> - especially if there's no replacement driver. Wouldn't it be better
> to try and get those BROKEN_ON_SMP drivers to become SMP safe
> instead of just removing them (or just leave them as-is if they work
> for some people on UP)?

> As for the lack of an active maintainer being a partial reason for
> removal. I don't agree with that. As long as the code works and gets
> fixed up to continue working when other parts of the kernel evolve,
> then I see no reason to remove the code just because noone is
> actively maintaining it. Sometimes unmaintained code even grow new
> maintainers after a while.

your points are well taken.  i wasn't arguing *for* the removal of all
that stuff, i was simply asking for comments.  i can see adrian bunk
has already made some comments on the wiki page.  but if various
Kconfig entries explicitly advertise themselves as "OBSOLETE", that's
at least grounds for discussion as to whether it's time for something
to go.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/