other potential candidates for removal?

other potential candidates for removal?

[Robert P. J. Day]

   a while back, i threw together this wiki page:

http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed

feel free to comment.

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: other potential candidates for removal?

[Clemens Koller]

Robert P. J. Day schrieb:
>    a while back, i threw together this wiki page:
> 
> http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
> 
> feel free to comment.

Won't miss anything there.
However, removal of kernel_threads() needs some updated drivers...

Regards,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

Re: other potential candidates for removal?

[Robert P. J. Day]

On Wed, 18 Jul 2007, Clemens Koller wrote:

> Robert P. J. Day schrieb:
> >    a while back, i threw together this wiki page:
> >
> > http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
> >
> > feel free to comment.
>
> Won't miss anything there.
> However, removal of kernel_threads() needs some updated drivers...

well, i *did* note that that feature didn't look quite ready for
removal just yet.  :-)

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: other potential candidates for removal?

[Jesper Juhl]

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) ?  Same goes for other
IOCTL's on the list as well as the ulog support.

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.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: other potential candidates for removal?

[Robert P. J. Day]

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

Re: other potential candidates for removal?

[Jiri Slaby]

Robert P. J. Day napsal(a):
>    a while back, i threw together this wiki page:
> 
> http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
> 
> feel free to comment.

Stallion drivers

That would be both STALLION and ISTALLION which allegedly have no maintainer and
don't work on SMP (both are listed as depending on BROKEN_ON_SMP). (Were both of
these allegedly dead, or just ISTALLION?)

    Do they work on UP machines? Adrian Bunk 05:04, 18 July 2007 (PDT)

Yes.

-- 
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University