Re: so what *is* obsolete and removable?
Am 17.04.2007 17:33 schrieb Alan Cox: > On Tue, 17 Apr 2007 17:03:58 +0200 > Tilman Schmidt <[EMAIL PROTECTED]> 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: | .) 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: [EMAIL PROTECTED] Wehrhausweg 66 Fax: +49 228 4299019 53227 Bonn Germany signature.asc Description: OpenPGP digital signature
Re: so what *is* obsolete and removable?
On Tue, 17 Apr 2007 17:03:58 +0200 Tilman Schmidt <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: so what *is* obsolete and removable?
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 SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: so what *is* obsolete and removable?
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 SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: so what *is* obsolete and removable?
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: so what *is* obsolete and removable?
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 *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: so what *is* obsolete and removable?
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: [EMAIL PROTECTED] Wehrhausweg 66 Fax: +49 228 4299019 53227 Bonn Germany signature.asc Description: OpenPGP digital signature
Re: so what *is* obsolete and removable?
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 <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: so what *is* obsolete and removable?
On Sun, 15 Apr 2007, Jesper Juhl wrote: > On 15/04/07, Robert P. J. Day <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: so what *is* obsolete and removable?
On 15/04/07, Robert P. J. Day <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: so what *is* obsolete and removable?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
so what *is* obsolete and removable?
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 . ./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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
