so what *is* obsolete and removable?

so what *is* obsolete and removable?

[Robert P. J. Day]

  in a recent posting, ian anderson suggested that, before kernel
features are removed, they should spend a reasonable amount of time in
the feature removal file to give everyone fair warning.  if that's the
case, then there are a *bunch* of things that should perhaps be added
to that file real soon now just to start the clock ticking.

  as a trivial first observation, there are a load of options
described as "obsolete" in one way or another in the various Kconfig
files:

$ grep -iw obsolete $(find . -name Kconfig\*)
./net/sched/Kconfig:    bool "Traffic Policing (obsolete)"
./net/netfilter/Kconfig:        bool "Layer 3 Dependent Connection tracking (OBSOLETE)"
./net/netfilter/Kconfig:          This target replaced the old obsolete QUEUE target.
./net/ipv6/netfilter/Kconfig:   tristate "IP6 Userspace queueing via NETLINK (OBSOLETE)"
./net/ipv4/netfilter/Kconfig:   tristate "IP Userspace queueing via NETLINK (OBSOLETE)"
./net/ipv4/Kconfig:       This code is experimental and also obsolete. If you want to use it,
./net/bridge/netfilter/Kconfig: tristate "ebt: ulog support (OBSOLETE)"
./drivers/pcmcia/Kconfig:       bool "PCMCIA control ioctl (obsolete)"
./drivers/net/wireless/Kconfig:# Note : the cards are obsolete (can't buy them anymore), but the drivers
./drivers/net/wireless/Kconfig:comment "Obsolete Wireless cards support (pre-802.11)"
./drivers/net/Kconfig:    new card, since the 3c501 is slow, broken, and obsolete: you will
./drivers/net/Kconfig:  tristate "Traffic Shaper (OBSOLETE)"
./drivers/block/paride/Kconfig:   This option enables support for the (obsolete) EPIA parallel port
./drivers/block/paride/Kconfig:   This option enables support for the (obsolete) 90c20 parallel port
./drivers/block/Kconfig:          obsolete. For details, read <file:Documentation/ramdisk.txt>.
./drivers/sbus/char/Kconfig:    tristate "Bidirectional parallel port support (OBSOLETE)"
./drivers/sbus/char/Kconfig:      Say Y here to support Sun's obsolete variant of IEEE1284
./drivers/message/i2o/Kconfig:  bool "Enable ioctls (OBSOLETE)"
./drivers/char/Kconfig: tristate "Moxa SmartIO support (OBSOLETE)"
./drivers/char/Kconfig: tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
./drivers/mtd/chips/Kconfig:      select some other chip drivers which are now considered obsolete,
./drivers/isdn/Kconfig: tristate "Old ISDN4Linux (obsolete)"
./drivers/isdn/Kconfig:   Therefore the old ISDN4Linux layer is becoming obsolete. It is
./lib/Kconfig.debug:    bool "Enable unused/obsolete exported symbols"
./arch/i386/Kconfig:      1995 when it was made obsolete by the PCI bus.
./arch/arm/Kconfig:       1995 when it was made obsolete by the PCI bus.
./arch/sparc64/Kconfig:   1995 when it was made obsolete by the PCI bus.
./arch/m68k/Kconfig:      1995 when it was made obsolete by the PCI bus.
./arch/um/Kconfig.char:        tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
./arch/um/Kconfig:      into UML. This option is largely obsolete, given that skas0 provides
./arch/mips/Kconfig:      1995 when it was made obsolete by the PCI bus.
./arch/powerpc/platforms/iseries/Kconfig:       tristate "iSeries Virtual Console Support (Obsolete)"
./arch/sh/Kconfig:        1995 when it was made obsolete by the PCI bus.
./sound/core/Kconfig:     Say Y here to support the obsolete ALSA PCM API (ver.0.9.0 rc3
./sound/oss/Kconfig:    bool "Obsolete OSS drivers"
./sound/oss/Kconfig:      This option enables support for obsolete OSS drivers that

  clearly, that was a fairly brainless search, but it still reveals a
pile of stuff that's "obsolete" (whatever that means in the context in
which it's used).  so what's really obsolete?

  as i recall, the isdn4linux was *un*obsoleted, wasn't it?  and raw
drivers are going to be kept around for a while longer.  so what's
legitimately dead?  or what should be added to the feature removal
schedule?  or, if it's not really "obsolete," perhaps it shouldn't be
described that way.

  just my $0.02 (Cdn).

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: so what *is* obsolete and removable?

[Jiri Slaby]

Robert P. J. Day napsal(a):
> ./drivers/char/Kconfig: tristate "Moxa SmartIO support (OBSOLETE)"

Yes, I'm going to add it to the schedule shortly -- will post patch with
correcting bad Kconfig info after some bugfixes of mxser_new.

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: so what *is* obsolete and removable?

[Jesper Juhl]

On 15/04/07, Robert P. J. Day <rpjday@mindspring.com> wrote:
>
>   in a recent posting, ian anderson suggested that, before kernel
> features are removed, they should spend a reasonable amount of time in
> the feature removal file to give everyone fair warning.  if that's the
> case, then there are a *bunch* of things that should perhaps be added
> to that file real soon now just to start the clock ticking.
>
[snip]
> ./sound/oss/Kconfig:    bool "Obsolete OSS drivers"
> ./sound/oss/Kconfig:      This option enables support for obsolete OSS drivers that
>
>   clearly, that was a fairly brainless search, but it still reveals a
> pile of stuff that's "obsolete" (whatever that means in the context in
> which it's used).  so what's really obsolete?
>
IIRC Adrian Bunk is handling the removal of obsolete OSS drivers and
doing a nice job at it. Dunno about the rest of the stuff.

-- 
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: so what *is* obsolete and removable?

[Robert P. J. Day]

On Sun, 15 Apr 2007, Jesper Juhl wrote:

> On 15/04/07, Robert P. J. Day <rpjday@mindspring.com> wrote:
> >
> >   in a recent posting, ian anderson suggested that, before kernel
> > features are removed, they should spend a reasonable amount of
> > time in the feature removal file to give everyone fair warning.
> > if that's the case, then there are a *bunch* of things that should
> > perhaps be added to that file real soon now just to start the
> > clock ticking.
> >
> [snip]
> > ./sound/oss/Kconfig:    bool "Obsolete OSS drivers"
> > ./sound/oss/Kconfig:      This option enables support for obsolete OSS
> > drivers that
> >
> >   clearly, that was a fairly brainless search, but it still
> > reveals a pile of stuff that's "obsolete" (whatever that means in
> > the context in which it's used).  so what's really obsolete?
> >
> IIRC Adrian Bunk is handling the removal of obsolete OSS drivers and
> doing a nice job at it. Dunno about the rest of the stuff.

oh, i realize that a number of those examples from my earlier post
were already handled/being handled (i don't even look under OSS these
days when doing any cleanup).

my point was that, if ian's position is valid and stuff shouldn't be
removed without fair warning, then a lot of that stuff should get
entered into the feature removal file real soon now.

rday

p.s.  again, if you run the simple grep i mentioned before:

  $ grep -iw obsolete $(find . -name Kconfig\*)

you find some odd combinations, such as this from net/ipv4/Kconfig:

config ARPD
        bool "IP: ARP daemon support (EXPERIMENTAL)"
        depends on EXPERIMENTAL
        ---help---
        ...
        This code is experimental and also obsolete...

the thought of something being both experimental *and* obsolete is a
bit weird, is it not?

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

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

Re: so what *is* obsolete and removable?

[Adrian Bunk]

On Mon, Apr 16, 2007 at 10:44:52AM -0400, Robert P. J. Day wrote:
> On Sun, 15 Apr 2007, Jesper Juhl wrote:
> 
> > On 15/04/07, Robert P. J. Day <rpjday@mindspring.com> wrote:
> > >
> > >   in a recent posting, ian anderson suggested that, before kernel
> > > features are removed, they should spend a reasonable amount of
> > > time in the feature removal file to give everyone fair warning.
> > > if that's the case, then there are a *bunch* of things that should
> > > perhaps be added to that file real soon now just to start the
> > > clock ticking.
> > >
> > [snip]
> > > ./sound/oss/Kconfig:    bool "Obsolete OSS drivers"
> > > ./sound/oss/Kconfig:      This option enables support for obsolete OSS
> > > drivers that
> > >
> > >   clearly, that was a fairly brainless search, but it still
> > > reveals a pile of stuff that's "obsolete" (whatever that means in
> > > the context in which it's used).  so what's really obsolete?
> > >
> > IIRC Adrian Bunk is handling the removal of obsolete OSS drivers and
> > doing a nice job at it. Dunno about the rest of the stuff.
> 
> oh, i realize that a number of those examples from my earlier post
> were already handled/being handled (i don't even look under OSS these
> days when doing any cleanup).
> 
> my point was that, if ian's position is valid and stuff shouldn't be
> removed without fair warning, then a lot of that stuff should get
> entered into the feature removal file real soon now.

If you remove false positives from your grep result, "a lot" turns into 
a relatively small number.

But generally, you should try to ask the maintainers of the subsystem 
first what they think.

Whether to remove something now, in 6 months, or not, can then be 
decided.

> rday
> 
> p.s.  again, if you run the simple grep i mentioned before:
> 
>   $ grep -iw obsolete $(find . -name Kconfig\*)
> 
> you find some odd combinations, such as this from net/ipv4/Kconfig:
> 
> config ARPD
>         bool "IP: ARP daemon support (EXPERIMENTAL)"
>         depends on EXPERIMENTAL
>         ---help---
>         ...
>         This code is experimental and also obsolete...
> 
> the thought of something being both experimental *and* obsolete is a
> bit weird, is it not?

It is not weird:
It was never more than experimental, and now it's obsolete.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: so what *is* obsolete and removable?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

Am 15.04.2007 22:55 schrieb Robert P. J. Day:
>   as i recall, the isdn4linux was *un*obsoleted, wasn't it?

Actually, it wasn't.

We *did* reach a consensus that isdn4linux is not obsolete in the
accepted sense of the word, because there is no replacement for it
so far.

OTOH I have since submitted (twice, in fact) a patch that would remove
the "(obsolete)" label from the Kconfig entry, but somehow nothing
ever became of it. My submissions just linger in LKML, uncommented and
unmerged.

To sum it up, we agree that the "(obsolete)" label is wrong, but we
won't remove it. I have no idea how to resolve that situation.

What I do know is that it would be very wrong to remove isdn4linux,
because it has an existing userbase with nowhere else to go.

-- 
Tilman Schmidt                                  E-Mail: tilman@imap.cc
Wehrhausweg 66                                  Fax: +49 228 4299019
53227 Bonn
Germany


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: so what *is* obsolete and removable?

[Randy Dunlap]

On Tue, 17 Apr 2007 00:39:10 +0200 Tilman Schmidt wrote:

> Am 15.04.2007 22:55 schrieb Robert P. J. Day:
> >   as i recall, the isdn4linux was *un*obsoleted, wasn't it?
> 
> Actually, it wasn't.
> 
> We *did* reach a consensus that isdn4linux is not obsolete in the
> accepted sense of the word, because there is no replacement for it
> so far.
> 
> OTOH I have since submitted (twice, in fact) a patch that would remove
> the "(obsolete)" label from the Kconfig entry, but somehow nothing
> ever became of it. My submissions just linger in LKML, uncommented and
> unmerged.

Did you submit the patch to Andrew Morton?
Is the patch in the -mm patchset?
Did Karsten ack the patch?

If the patch is in -mm and it's not critical (like this subject),
then it probably won't be merged until after 2.6.21 is released...


> To sum it up, we agree that the "(obsolete)" label is wrong, but we
> won't remove it. I have no idea how to resolve that situation.
> 
> What I do know is that it would be very wrong to remove isdn4linux,
> because it has an existing userbase with nowhere else to go.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: so what *is* obsolete and removable?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Mon, 16 Apr 2007 16:13:37 -0700, Randy Dunlap wrote:
> On Tue, 17 Apr 2007 00:39:10 +0200 Tilman Schmidt wrote:
> 
>> We *did* reach a consensus that isdn4linux is not obsolete in the
>> accepted sense of the word, because there is no replacement for it
>> so far.
>> 
>> OTOH I have since submitted (twice, in fact) a patch that would remove
>> the "(obsolete)" label from the Kconfig entry, but somehow nothing
>> ever became of it. My submissions just linger in LKML, uncommented and
>> unmerged.
> 
> Did you submit the patch to Andrew Morton?

No. The recipients I chose were Karsten Keil as the subsystem
maintainer, i4ldeveloper as the subsystem specific list, and LKML.

> Is the patch in the -mm patchset?

No. Should it be? It's not as if there was anything to test.
It's purely a textual change in Kconfig messages.

> Did Karsten ack the patch?

No. He hasn't replied at all.

> If the patch is in -mm and it's not critical (like this subject),
> then it probably won't be merged until after 2.6.21 is released...

Fine by me, as long as it does get merged eventually so I can stop
watching for attempts to remove isdn4linux as obsolete.

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: so what *is* obsolete and removable?

[Alan Cox]

> > If the patch is in -mm and it's not critical (like this subject),
> > then it probably won't be merged until after 2.6.21 is released...
> 
> Fine by me, as long as it does get merged eventually so I can stop
> watching for attempts to remove isdn4linux as obsolete.

If the obsolete tag is to be removed then it needs a formal maintainer,
all the obsolete interface usage cleaning up and the like otherwise at
some point in a clean up it is going to end up breaking and migrating to
&& BROKEN as well.

If that is going to get done (by Karsten or someone else given Karsten
appears totally occupied on other stuff) then great.

Alan

Re: so what *is* obsolete and removable?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Tue, 17 Apr 2007 14:40:54 +0100, Alan Cox wrote:
> If the obsolete tag is to be removed then it needs a formal maintainer,
> all the obsolete interface usage cleaning up and the like otherwise at
> some point in a clean up it is going to end up breaking and migrating to
> && BROKEN as well.

I'm not sure I understand. What do you mean by "obsolete interface
usage"? What sort of cleaning up needs to be done? What sort of
breakage do you anticipate in the event of a clean up?

Thanks
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: so what *is* obsolete and removable?

[Alan Cox]

On Tue, 17 Apr 2007 17:03:58 +0200
Tilman Schmidt <tilman@imap.cc> wrote:

> On Tue, 17 Apr 2007 14:40:54 +0100, Alan Cox wrote:
> > If the obsolete tag is to be removed then it needs a formal maintainer,
> > all the obsolete interface usage cleaning up and the like otherwise at
> > some point in a clean up it is going to end up breaking and migrating to
> > && BROKEN as well.
> 
> I'm not sure I understand. What do you mean by "obsolete interface
> usage"? What sort of cleaning up needs to be done? What sort of
> breakage do you anticipate in the event of a clean up?

Things like:

	pci_find_device
	pci_find_bus

	interruptible_sleep_on
	sleep_on

	lock_kernel
	unlock_kernel

and the drivers that i4l uses (eg hisax) need switching to the proper
pci_module interfaces to handle hot plug.

Re: so what *is* obsolete and removable?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 3386 bytes --]

Am 17.04.2007 17:33 schrieb Alan Cox:
> On Tue, 17 Apr 2007 17:03:58 +0200
> Tilman Schmidt <tilman@imap.cc> wrote:
> 
>> On Tue, 17 Apr 2007 14:40:54 +0100, Alan Cox wrote:
>>> If the obsolete tag is to be removed then it needs a formal maintainer,
>>> all the obsolete interface usage cleaning up and the like otherwise at
>>> some point in a clean up it is going to end up breaking and migrating to
>>> && BROKEN as well.
>> I'm not sure I understand. What do you mean by "obsolete interface
>> usage"? What sort of cleaning up needs to be done? What sort of
>> breakage do you anticipate in the event of a clean up?
> 
> Things like:
> 
> 	pci_find_device
> 	pci_find_bus
> 
> 	interruptible_sleep_on
> 	sleep_on
> 
> 	lock_kernel
> 	unlock_kernel
> 
> and the drivers that i4l uses (eg hisax) need switching to the proper
> pci_module interfaces to handle hot plug.

I was afraid you meant that. You are confirming my worst fears.
So it's already too late, and that incorrect obsolete tag is on its
way to becoming a self-fulfilling prophecy. Whatever happened to the
promise in Documentation/stable_api_nonsense.txt:

| <insert link to leech comment from Andrew and Linus here>.)  If your
| driver is in the tree, and a kernel interface changes, it will be fixed
| up by the person who did the kernel change in the first place.  This
| ensures that your driver is always buildable, and works over time, with
| very little effort on your part.

?

Let me guess: the person who did the kernel change in the first place
saw that I4L was marked as obsolete anyway, and therefore didn't bother
fixing it up. And now that very fact constitutes a reason to keep that
label, ensuring that future people doing kernel changes will do
likewise. So the cat is biting its own tail, as we say in German.

Well, end of rant. So the situation now is:
- A discussion on LKML concluded that the isdn4linux subsystem is not
  obsolete today, given that a complete replacement does not yet exist.
- The "obsolete" tag on the ISDN_I4L Kconfig entry is therefore
  incorrect.
- In order to remove it, you ask that the code of the isdn4linux
  subsystem be modified to conform to certain changes that have been
  made to the kernel API but not extended to isdn4linux.
- The people best qualified to make these modifications are
  (a) those who introduced the kernel API changes in the first place or
  (b) the isdn4linux maintainers.
- The isdn4linux maintainers are busy working on the new CAPI subsystem
  and mISDN driver which should replace isdn4linux eventually but are
  not quite there yet. (mISDN not even being in the kernel so far.)
- That leaves those who introduced the kernel API changes in question
  to finish what is, according to stable_api_nonsense.txt, their job.
- In the meantime, we'll have to live with the recurring question
  whether the isdn4linux subsystem can finally be scheduled for removal.
- At least we are safe against an actual removal, because that would
  constitute a regression (break existing functionality that is in
  actual use), and Linus says we don't do regressions.

Did I sum that up correctly?

Thanks
Tilman

-- 
Tilman Schmidt                                  E-Mail: tilman@imap.cc
Wehrhausweg 66                                  Fax: +49 228 4299019
53227 Bonn
Germany


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]