Re: Feature Removals for 2.6.25
On 15-02-08 00:20, David Newall wrote: Arjan van de Ven wrote: Bill Davidsen wrote: Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. the problem is that the new one DOES NOT GET FIXED. THAT is a huge problem; it means we have a buggy driver... If the old one works and the new one is buggy, it begs the question of why anybody bothered writing a new one in the first place. "If it ain't broke, don't fix it," might have been good advice to follow. Not generally. A usual scenario is the new driver working on newer hardware versions than the old one supports but not necessarily on all the old ones the previous driver supported if only due to to availability of the older hardware for testing. Rene. -- 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: Feature Removals for 2.6.25
Arjan van de Ven wrote: > Bill Davidsen wrote: >> Note that because the hardware is old, it's highly likely that most >> of it will be retired before that sk98lin driver needs a change. I >> can't see anyone using sk98lin on a new system, so it would be less >> contentious to let the hardware (or users) die of natural causes if >> you can. >> > > the problem is that the new one DOES NOT GET FIXED. > THAT is a huge problem; it means we have a buggy driver... If the old one works and the new one is buggy, it begs the question of why anybody bothered writing a new one in the first place. "If it ain't broke, don't fix it," might have been good advice to follow. -- 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: Feature Removals for 2.6.25
On Thu, Feb 14, 2008 at 10:24:43AM -0800, Arjan van de Ven wrote: > Bill Davidsen wrote: > >Note that because the hardware is old, it's highly likely that most of > >it will be retired before that sk98lin driver needs a change. I can't > >see anyone using sk98lin on a new system, so it would be less > >contentious to let the hardware (or users) die of natural causes if you > >can. > > > > the problem is that the new one DOES NOT GET FIXED. > THAT is a huge problem; it means we have a buggy driver... It's also utterly missing the point. The skge driver supports all the hardware that sk98lin supports. If it doesn't work bug Stephen who's a very responsive maintainer. -- 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: Feature Removals for 2.6.25
Bill Davidsen wrote: Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. the problem is that the new one DOES NOT GET FIXED. THAT is a huge problem; it means we have a buggy driver... -- 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: Feature Removals for 2.6.25
Stephen Hemminger wrote: Ping? What: sk98lin network driver When: Feburary 2008 Why:In kernel tree version of driver is unmaintained. Sk98lin driver replaced by the skge driver. Who:Stephen Hemminger <[EMAIL PROTECTED]> --- We have been over this several times, and I thought someone had taken over the driver and was providing patches to put it in. Both skge and sky2 have been proposed as the replacement, people have reported problems with each. Suggest leaving this alone until the sk98lin actually needs work, then take it out. Problems in my problem system have been intermittent, take 4-40 hours to show and generate no errors, other than the driver thinks it's sending packets and the sniffer doesn't. The vendor sk98lin driver will continue it's happy life out of tree. The version in 2.6.25 is ancient and unmaintained and only supports older hardware. There are no outstanding issues with skge driver (sky2 is prone to hardware problems, but then so is vendor driver). And those of us who are using it *have* old hardware. Old hardware that perhaps the people forcing other driver on us don't have. Unfortunately, removing sk98lin seems to be the only way to make die hard users report problems. The last time we removed it, some user's of old Genesis boards showed with issues, but those are now fixed. I guess I have a real problem with the "make die hard users report problems" thing, because it assumes that there is nothing wrong with *causing* us problems. Understand, this is not "change is bad" but "change is expensive." Because it means a change in kernel config, modules.conf, and possibly rc.local or initrd or similar. A per-machine effort which is small in ones, and large in sum. Jeff has scheduled sk98lin for removal in 2.6.26. (and it will probably be gone from -mm before that). If this were a case of the sk98lin driver needing work, I wouldn't be making the argument. But to make work for users in a case where there is no saving in effort for developers, sounds as if the developers place no value at all on the time of the people who build their own kernels, and if the vendors are good with it, that's all that matters. Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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: Feature Removals for 2.6.25
On Thu, Feb 14, 2008 at 10:24:43AM -0800, Arjan van de Ven wrote: Bill Davidsen wrote: Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. the problem is that the new one DOES NOT GET FIXED. THAT is a huge problem; it means we have a buggy driver... It's also utterly missing the point. The skge driver supports all the hardware that sk98lin supports. If it doesn't work bug Stephen who's a very responsive maintainer. -- 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: Feature Removals for 2.6.25
Stephen Hemminger wrote: Ping? What: sk98lin network driver When: Feburary 2008 Why:In kernel tree version of driver is unmaintained. Sk98lin driver replaced by the skge driver. Who:Stephen Hemminger [EMAIL PROTECTED] --- We have been over this several times, and I thought someone had taken over the driver and was providing patches to put it in. Both skge and sky2 have been proposed as the replacement, people have reported problems with each. Suggest leaving this alone until the sk98lin actually needs work, then take it out. Problems in my problem system have been intermittent, take 4-40 hours to show and generate no errors, other than the driver thinks it's sending packets and the sniffer doesn't. The vendor sk98lin driver will continue it's happy life out of tree. The version in 2.6.25 is ancient and unmaintained and only supports older hardware. There are no outstanding issues with skge driver (sky2 is prone to hardware problems, but then so is vendor driver). And those of us who are using it *have* old hardware. Old hardware that perhaps the people forcing other driver on us don't have. Unfortunately, removing sk98lin seems to be the only way to make die hard users report problems. The last time we removed it, some user's of old Genesis boards showed with issues, but those are now fixed. I guess I have a real problem with the make die hard users report problems thing, because it assumes that there is nothing wrong with *causing* us problems. Understand, this is not change is bad but change is expensive. Because it means a change in kernel config, modules.conf, and possibly rc.local or initrd or similar. A per-machine effort which is small in ones, and large in sum. Jeff has scheduled sk98lin for removal in 2.6.26. (and it will probably be gone from -mm before that). If this were a case of the sk98lin driver needing work, I wouldn't be making the argument. But to make work for users in a case where there is no saving in effort for developers, sounds as if the developers place no value at all on the time of the people who build their own kernels, and if the vendors are good with it, that's all that matters. Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. -- Bill Davidsen [EMAIL PROTECTED] Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark -- 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: Feature Removals for 2.6.25
Bill Davidsen wrote: Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. the problem is that the new one DOES NOT GET FIXED. THAT is a huge problem; it means we have a buggy driver... -- 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: Feature Removals for 2.6.25
Arjan van de Ven wrote: Bill Davidsen wrote: Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. the problem is that the new one DOES NOT GET FIXED. THAT is a huge problem; it means we have a buggy driver... If the old one works and the new one is buggy, it begs the question of why anybody bothered writing a new one in the first place. If it ain't broke, don't fix it, might have been good advice to follow. -- 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: Feature Removals for 2.6.25
On 15-02-08 00:20, David Newall wrote: Arjan van de Ven wrote: Bill Davidsen wrote: Note that because the hardware is old, it's highly likely that most of it will be retired before that sk98lin driver needs a change. I can't see anyone using sk98lin on a new system, so it would be less contentious to let the hardware (or users) die of natural causes if you can. the problem is that the new one DOES NOT GET FIXED. THAT is a huge problem; it means we have a buggy driver... If the old one works and the new one is buggy, it begs the question of why anybody bothered writing a new one in the first place. If it ain't broke, don't fix it, might have been good advice to follow. Not generally. A usual scenario is the new driver working on newer hardware versions than the old one supports but not necessarily on all the old ones the previous driver supported if only due to to availability of the older hardware for testing. Rene. -- 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: Feature Removals for 2.6.25
> > > Ping? > > What: sk98lin network driver > > When: Feburary 2008 > > Why:In kernel tree version of driver is unmaintained. Sk98lin driver > > replaced by the skge driver. > > Who:Stephen Hemminger <[EMAIL PROTECTED]> > > > > --- > > We have been over this several times, and I thought someone had taken > over the driver and was providing patches to put it in. Both skge and > sky2 have been proposed as the replacement, people have reported > problems with each. Suggest leaving this alone until the sk98lin > actually needs work, then take it out. Problems in my problem system > have been intermittent, take 4-40 hours to show and generate no errors, > other than the driver thinks it's sending packets and the sniffer doesn't. The vendor sk98lin driver will continue it's happy life out of tree. The version in 2.6.25 is ancient and unmaintained and only supports older hardware. There are no outstanding issues with skge driver (sky2 is prone to hardware problems, but then so is vendor driver). Unfortunately, removing sk98lin seems to be the only way to make die hard users report problems. The last time we removed it, some user's of old Genesis boards showed with issues, but those are now fixed. Jeff has scheduled sk98lin for removal in 2.6.26. (and it will probably be gone from -mm before that). -- 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: Feature Removals for 2.6.25
Harvey Harrison wrote: What: CONFIG_FORCED_INLINING When: June 2006 Why:Config option is there to see if gcc is good enough. (in january 2006). If it is, the behavior should just be the default. If it's not, the option should just go away entirely. Who:Arjan van de Ven Patch submitted to Arjan, maybe 2.6.25? --- The "good enough" of gcc may be architecture dependent. Taking the option away where it works because somewhere else it doesn't may not be the optimal solution. Ping? What: eepro100 network driver When: January 2007 Why:replaced by the e100 driver Who:Adrian Bunk <[EMAIL PROTECTED]> --- The last time we discussed this the team working on e100 said there were still issues (IIRC). Have they all been resolved? Ping? What: sk98lin network driver When: Feburary 2008 Why:In kernel tree version of driver is unmaintained. Sk98lin driver replaced by the skge driver. Who:Stephen Hemminger <[EMAIL PROTECTED]> --- We have been over this several times, and I thought someone had taken over the driver and was providing patches to put it in. Both skge and sky2 have been proposed as the replacement, people have reported problems with each. Suggest leaving this alone until the sk98lin actually needs work, then take it out. Problems in my problem system have been intermittent, take 4-40 hours to show and generate no errors, other than the driver thinks it's sending packets and the sniffer doesn't. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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: Feature Removals for 2.6.25
Ping? What: sk98lin network driver When: Feburary 2008 Why:In kernel tree version of driver is unmaintained. Sk98lin driver replaced by the skge driver. Who:Stephen Hemminger [EMAIL PROTECTED] --- We have been over this several times, and I thought someone had taken over the driver and was providing patches to put it in. Both skge and sky2 have been proposed as the replacement, people have reported problems with each. Suggest leaving this alone until the sk98lin actually needs work, then take it out. Problems in my problem system have been intermittent, take 4-40 hours to show and generate no errors, other than the driver thinks it's sending packets and the sniffer doesn't. The vendor sk98lin driver will continue it's happy life out of tree. The version in 2.6.25 is ancient and unmaintained and only supports older hardware. There are no outstanding issues with skge driver (sky2 is prone to hardware problems, but then so is vendor driver). Unfortunately, removing sk98lin seems to be the only way to make die hard users report problems. The last time we removed it, some user's of old Genesis boards showed with issues, but those are now fixed. Jeff has scheduled sk98lin for removal in 2.6.26. (and it will probably be gone from -mm before that). -- 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: Feature Removals for 2.6.25
Harvey Harrison wrote: What: CONFIG_FORCED_INLINING When: June 2006 Why:Config option is there to see if gcc is good enough. (in january 2006). If it is, the behavior should just be the default. If it's not, the option should just go away entirely. Who:Arjan van de Ven Patch submitted to Arjan, maybe 2.6.25? --- The good enough of gcc may be architecture dependent. Taking the option away where it works because somewhere else it doesn't may not be the optimal solution. Ping? What: eepro100 network driver When: January 2007 Why:replaced by the e100 driver Who:Adrian Bunk [EMAIL PROTECTED] --- The last time we discussed this the team working on e100 said there were still issues (IIRC). Have they all been resolved? Ping? What: sk98lin network driver When: Feburary 2008 Why:In kernel tree version of driver is unmaintained. Sk98lin driver replaced by the skge driver. Who:Stephen Hemminger [EMAIL PROTECTED] --- We have been over this several times, and I thought someone had taken over the driver and was providing patches to put it in. Both skge and sky2 have been proposed as the replacement, people have reported problems with each. Suggest leaving this alone until the sk98lin actually needs work, then take it out. Problems in my problem system have been intermittent, take 4-40 hours to show and generate no errors, other than the driver thinks it's sending packets and the sniffer doesn't. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- 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: Feature Removals for 2.6.25 - old NCR53C9x driver
On Fri, Feb 01 2008 at 3:38 +0200, Harvey Harrison <[EMAIL PROTECTED]> wrote: > The following are entries in feature-removal-schedule.txt that have > come due. Please change the subject when replying to specific items. > > Where I've gotten responses from the named person in the file, I've > included their comment. > > --- > > What: old NCR53C9x driver > When: October 2007 > Why: Replaced by the much better esp_scsi driver. Actual low-level > driver can be ported over almost trivially. > Who: David Miller <[EMAIL PROTECTED]> > Christoph Hellwig <[EMAIL PROTECTED]> > > DaveM: Likely one more release with this, perhaps delete 2.6.26 > --- This has been done and is currently in scsi-misc awaiting for a pull. -- 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: Feature Removals for 2.6.25 - old NCR53C9x driver
On Fri, Feb 01 2008 at 3:38 +0200, Harvey Harrison [EMAIL PROTECTED] wrote: The following are entries in feature-removal-schedule.txt that have come due. Please change the subject when replying to specific items. Where I've gotten responses from the named person in the file, I've included their comment. --- What: old NCR53C9x driver When: October 2007 Why: Replaced by the much better esp_scsi driver. Actual low-level driver can be ported over almost trivially. Who: David Miller [EMAIL PROTECTED] Christoph Hellwig [EMAIL PROTECTED] DaveM: Likely one more release with this, perhaps delete 2.6.26 --- This has been done and is currently in scsi-misc awaiting for a pull. -- 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: Feature Removals for 2.6.25
On Thu, Jan 31, 2008 at 05:38:42PM -0800, Harvey Harrison wrote: > --- > Ping? > What: vm_ops.nopage > When: Soon, provided in-kernel callers have been converted > Why: This interface is replaced by vm_ops.fault, but it has been around > forever, is used by a lot of drivers, and doesn't cost much to > maintain. > Who: Nick Piggin <[EMAIL PROTECTED]> Well the in-kernel callers have not all been converted yet. I have actually done the work, but it needs testing and merging by maintainers. Getting it done during this merge window would be nice, I'm going to try to make that happen after I get back from LCA. Otherwise probably 2.6.26. -- 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: Removing dev.power.power_state (WAS: Feature Removals for 2.6.25)
On Friday 01 February 2008, Alan Stern wrote: > > I can look at the USB and SCSI stuff. It shouldn't be all that bad. > The userspace interface has been gone for quite some time now, and most > of the remaining uses of that field are write-only. It's that "most" which can make trouble. :) - Dave -- 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: Removing dev.power.power_state (WAS: Feature Removals for 2.6.25)
On Thursday 31 January 2008, David Brownell wrote: > Quoth Harvey Harrison: > > > Ping? > > What: dev->power.power_state > > When: July 2007 > > ... there are still quite a few users left, and a new one was (sigh) > recently added. > > - drivers/rtc/rtc-sa1100.c ... new usage, merged last week Fixed in a patch I just sent. > - drivers/spi/... some controller drivers use this (look easy to fix) Ditto. - Dave -- 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: Removing dev.power.power_state (WAS: Feature Removals for 2.6.25)
On Thu, 31 Jan 2008, David Brownell wrote: > Quoth Harvey Harrison: > > > Ping? > > What: dev->power.power_state > > When: July 2007 > > Why:Broken design for runtime control over driver power states, > > confusing > > driver-internal runtime power management with: mechanisms to support > > system-wide sleep state transitions; event codes that distinguish > > different phases of swsusp "sleep" transitions; and userspace policy > > inputs. This framework was never widely used, and most attempts to > > use it were broken. Drivers should instead be exposing domain-specific > > interfaces either to kernel or to userspace. > > Who:Pavel Machek <[EMAIL PROTECTED]> > > A lot of the infrastructure using that has already been deleted, and > there are some incremental improvements pending for 2.6.25: > But there are still quite a few users left, and a new one was (sigh) > recently added. > - drivers/usb/... has various users, HCDs look easy enough to fix but >the other bits will take more thought > - drivers/scsi/mesh.c > I'll probably send in a few more patches for easy stuff in areas > that I touch semi-frequently, but other folk should fix ATA, IDE, > SCSI, SERIO, and so forth. It'd be good if Alan would help fix > the USB stuff too. I'm not sure what Pavel's doing there... I can look at the USB and SCSI stuff. It shouldn't be all that bad. The userspace interface has been gone for quite some time now, and most of the remaining uses of that field are write-only. Alan Stern -- 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: Removing dev.power.power_state (WAS: Feature Removals for 2.6.25)
On Thu, 31 Jan 2008, David Brownell wrote: Quoth Harvey Harrison: Ping? What: dev-power.power_state When: July 2007 Why:Broken design for runtime control over driver power states, confusing driver-internal runtime power management with: mechanisms to support system-wide sleep state transitions; event codes that distinguish different phases of swsusp sleep transitions; and userspace policy inputs. This framework was never widely used, and most attempts to use it were broken. Drivers should instead be exposing domain-specific interfaces either to kernel or to userspace. Who:Pavel Machek [EMAIL PROTECTED] A lot of the infrastructure using that has already been deleted, and there are some incremental improvements pending for 2.6.25: But there are still quite a few users left, and a new one was (sigh) recently added. - drivers/usb/... has various users, HCDs look easy enough to fix but the other bits will take more thought - drivers/scsi/mesh.c I'll probably send in a few more patches for easy stuff in areas that I touch semi-frequently, but other folk should fix ATA, IDE, SCSI, SERIO, and so forth. It'd be good if Alan would help fix the USB stuff too. I'm not sure what Pavel's doing there... I can look at the USB and SCSI stuff. It shouldn't be all that bad. The userspace interface has been gone for quite some time now, and most of the remaining uses of that field are write-only. Alan Stern -- 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: Removing dev.power.power_state (WAS: Feature Removals for 2.6.25)
On Thursday 31 January 2008, David Brownell wrote: Quoth Harvey Harrison: Ping? What: dev-power.power_state When: July 2007 ... there are still quite a few users left, and a new one was (sigh) recently added. - drivers/rtc/rtc-sa1100.c ... new usage, merged last week Fixed in a patch I just sent. - drivers/spi/... some controller drivers use this (look easy to fix) Ditto. - Dave -- 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: Feature Removals for 2.6.25
On Thu, Jan 31, 2008 at 05:38:42PM -0800, Harvey Harrison wrote: --- Ping? What: vm_ops.nopage When: Soon, provided in-kernel callers have been converted Why: This interface is replaced by vm_ops.fault, but it has been around forever, is used by a lot of drivers, and doesn't cost much to maintain. Who: Nick Piggin [EMAIL PROTECTED] Well the in-kernel callers have not all been converted yet. I have actually done the work, but it needs testing and merging by maintainers. Getting it done during this merge window would be nice, I'm going to try to make that happen after I get back from LCA. Otherwise probably 2.6.26. -- 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: Feature Removals for 2.6.25
> Ping? > What: sk98lin network driver > When: Feburary 2008 > Why:In kernel tree version of driver is unmaintained. Sk98lin driver > replaced by the skge driver. > Who:Stephen Hemminger <[EMAIL PROTECTED]> > Sent a removal patch to Jeff, it probably was too big for the mailing list. -- Stephen Hemminger <[EMAIL PROTECTED]> -- 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: Feature Removals for 2.6.25
On Thu, 2008-01-31 at 22:33 -0800, Arjan van de Ven wrote: > Harvey Harrison wrote: > > Something like the following (grep found me two example symbols) > > to be honest, nobody reads this file with such detail; the actual UNUSED > marking > is a lot more louder and people are more likely to notice those for all I > care > we nuke the entire entry from the removals file. Well, if there is interest in having an up-to-date file, I'm willing to do the bookkeeping to make this usable and try to keep it up to date. Anybody think this is worthwhile? Harvey -- 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: Feature Removals for 2.6.25
Harvey Harrison wrote: Something like the following (grep found me two example symbols) to be honest, nobody reads this file with such detail; the actual UNUSED marking is a lot more louder and people are more likely to notice those for all I care we nuke the entire entry from the removals file. -- 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/
Removing dev.power.power_state (WAS: Feature Removals for 2.6.25)
Quoth Harvey Harrison: > Ping? > What: dev->power.power_state > When: July 2007 > Why: Broken design for runtime control over driver power states, confusing > driver-internal runtime power management with: mechanisms to support > system-wide sleep state transitions; event codes that distinguish > different phases of swsusp "sleep" transitions; and userspace policy > inputs. This framework was never widely used, and most attempts to > use it were broken. Drivers should instead be exposing domain-specific > interfaces either to kernel or to userspace. > Who: Pavel Machek <[EMAIL PROTECTED]> A lot of the infrastructure using that has already been deleted, and there are some incremental improvements pending for 2.6.25: - drivers/input/touchscreen/ads7846.c ... patch fixing this should be in either MM or the input queue - Documentation/power/devices.txt ... patch fixing this is in the suspend tree, due to merge RSN - drivers/spi/spi.c ... patch fixing this is in MM, due to merge with other SPI patches - drivers/pcmcia/ds.c ... at least I *think* that patch got sent But there are still quite a few users left, and a new one was (sigh) recently added. - drivers/rtc/rtc-sa1100.c ... new usage, merged last week - drivers/usb/... has various users, HCDs look easy enough to fix but the other bits will take more thought - drivers/ata/... has some too - drivers/ide/ppc/pmac.c - drivers/spi/... some controller drivers use this (look easy to fix) - drivers/scsi/mesh.c - drivers/input/serio/... has a few users - ... more ... I'll probably send in a few more patches for easy stuff in areas that I touch semi-frequently, but other folk should fix ATA, IDE, SCSI, SERIO, and so forth. It'd be good if Alan would help fix the USB stuff too. I'm not sure what Pavel's doing there... - Dave -- 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: Feature Removals for 2.6.25
On Thu, 2008-01-31 at 20:53 -0800, Arjan van de Ven wrote: > > > > --- > > > > What: CONFIG_FORCED_INLINING > > When: June 2006 > > Why:Config option is there to see if gcc is good enough. (in january > > 2006). If it is, the behavior should just be the default. If it's > > not, > > the option should just go away entirely. > > Who:Arjan van de Ven > > > > Patch submitted to Arjan, maybe 2.6.25? > > Ingo picked it up, but no rush for .25, .26 is fine for this as well > OK, it shouldn't be any change from what's there now, but no rush. > > > > What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports > > (temporary transition config option provided until then) > > The transition config option will also be removed at the same time. > > When: before 2.6.19 > > Why:Unused symbols are both increasing the size of the kernel binary > > and are often a sign of "wrong API" > > Who:Arjan van de Ven <[EMAIL PROTECTED]> > > this is an ongoing work; symbols get marked unused and then garbage collected > when they're due; for example akpm has several of that kind in his pile right > now How do they get marked? As this is an ongoing effort, should this be moved to the top of the file, and the actual symbols+date be listed? That would make it easy to figure out what's going away. Something like the following (grep found me two example symbols) Harvey --- From: Harvey Harrison <[EMAIL PROTECTED]> Subject: [PATCH] feature-removal: document symbols going away Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- Documentation/feature-removal-schedule.txt | 25 +++-- 1 files changed, 15 insertions(+), 10 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 3a46d1f..0c418e6 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -5,6 +5,21 @@ the work. When the feature is removed from the kernel, it should also be removed from this file. --- +What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports + (temporary transition config option provided until then) + The transition config option will also be removed at the same time. +Why: Unused symbols are both increasing the size of the kernel binary + and are often a sign of "wrong API" +Who: Arjan van de Ven <[EMAIL PROTECTED]> + +When: 2.6.25 +fs/open.c:sys_open +fs/read_write.c:sys_read + +When: 2.6.26 + + +--- What: MXSER When: December 2007 @@ -137,16 +152,6 @@ Who:Adrian Bunk <[EMAIL PROTECTED]> --- -What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports - (temporary transition config option provided until then) - The transition config option will also be removed at the same time. -When: before 2.6.19 -Why: Unused symbols are both increasing the size of the kernel binary - and are often a sign of "wrong API" -Who: Arjan van de Ven <[EMAIL PROTECTED]> - - What: USB driver API moves to EXPORT_SYMBOL_GPL When: February 2008 Files: include/linux/usb.h, drivers/usb/core/driver.c -- 1.5.4.rc4.1142.gf5a97 -- 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: Feature Removals for 2.6.25 (USB driver api)
> --- > Ping? > What: USB driver API moves to EXPORT_SYMBOL_GPL > When: February 2008 > Files:include/linux/usb.h, drivers/usb/core/driver.c > Why: The USB subsystem has changed a lot over time, and it has been > possible to create userspace USB drivers using usbfs/libusb/gadgetfs > that operate as fast as the USB bus allows. Because of this, the USB > subsystem will not be allowing closed source kernel drivers to > register with it, after this grace period is over. If anyone needs > any help in converting their closed source drivers over to use the > userspace filesystems, please contact the > [EMAIL PROTECTED] mailing list, and the developers > there will be glad to help you out. > Who: Greg Kroah-Hartman <[EMAIL PROTECTED]> This is queued up in my tree to go to Linus, see my previous post on lkml and the linux-usb mailing list about this topic. thanks, greg k-h -- 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: Feature Removals for 2.6.25
--- What: CONFIG_FORCED_INLINING When: June 2006 Why:Config option is there to see if gcc is good enough. (in january 2006). If it is, the behavior should just be the default. If it's not, the option should just go away entirely. Who:Arjan van de Ven Patch submitted to Arjan, maybe 2.6.25? Ingo picked it up, but no rush for .25, .26 is fine for this as well What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports (temporary transition config option provided until then) The transition config option will also be removed at the same time. When: before 2.6.19 Why:Unused symbols are both increasing the size of the kernel binary and are often a sign of "wrong API" Who:Arjan van de Ven <[EMAIL PROTECTED]> this is an ongoing work; symbols get marked unused and then garbage collected when they're due; for example akpm has several of that kind in his pile right now -- 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/
Feature Removals for 2.6.25
The following are entries in feature-removal-schedule.txt that have come due. Please change the subject when replying to specific items. Where I've gotten responses from the named person in the file, I've included their comment. --- What: MXSER When: December 2007 Why:Old mxser driver is obsoleted by the mxser_new. Give it some time yet and remove it. Who:Jiri Slaby <[EMAIL PROTECTED]> Jiri says probably not for 2.6.25, likely 2.6.26 Patch in mm: http://userweb.kernel.org/~akpm/mmotm/broken-out/char-mxser-remove-it.patch --- Ping? What: dev->power.power_state When: July 2007 Why:Broken design for runtime control over driver power states, confusing driver-internal runtime power management with: mechanisms to support system-wide sleep state transitions; event codes that distinguish different phases of swsusp "sleep" transitions; and userspace policy inputs. This framework was never widely used, and most attempts to use it were broken. Drivers should instead be exposing domain-specific interfaces either to kernel or to userspace. Who:Pavel Machek <[EMAIL PROTECTED]> --- What: old NCR53C9x driver When: October 2007 Why:Replaced by the much better esp_scsi driver. Actual low-level driver can be ported over almost trivially. Who:David Miller <[EMAIL PROTECTED]> Christoph Hellwig <[EMAIL PROTECTED]> DaveM: Likely one more release with this, perhaps delete 2.6.26 --- Ping? What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) When: November 2005 Files: drivers/pcmcia/: pcmcia_ioctl.c Why:With the 16-bit PCMCIA subsystem now behaving (almost) like a normal hotpluggable bus, and with it using the default kernel infrastructure (hotplug, driver core, sysfs) keeping the PCMCIA control ioctl needed by cardmgr and cardctl from pcmcia-cs is unnecessary, and makes further cleanups and integration of the PCMCIA subsystem into the Linux kernel device driver model more difficult. The features provided by cardmgr and cardctl are either handled by the kernel itself now or are available in the new pcmciautils package available at http://kernel.org/pub/linux/utils/kernel/pcmcia/ Who:Dominik Brodowski <[EMAIL PROTECTED]> --- What: a.out interpreter support for ELF executables When: 2.6.25 Files: fs/binfmt_elf.c Why: Using a.out interpreters for ELF executables was a feature for transition from a.out to ELF. But now it is unlikely to be still needed anymore and removing it would simplify the hairy ELF loader code. Who: Andi Kleen <[EMAIL PROTECTED]> Patch in mm. --- Ping? What: remove EXPORT_SYMBOL(kernel_thread) When: August 2006 Files: arch/*/kernel/*_ksyms.c Check: kernel_thread Why:kernel_thread is a low-level implementation detail. Drivers should use the API instead which shields them from implementation details and provides a higherlevel interface that prevents bugs and code duplication Who:Christoph Hellwig <[EMAIL PROTECTED]> --- What: CONFIG_FORCED_INLINING When: June 2006 Why:Config option is there to see if gcc is good enough. (in january 2006). If it is, the behavior should just be the default. If it's not, the option should just go away entirely. Who:Arjan van de Ven Patch submitted to Arjan, maybe 2.6.25? --- Ping? What: eepro100 network driver When: January 2007 Why:replaced by the e100 driver Who:Adrian Bunk <[EMAIL PROTECTED]> --- Ping? Possibly remove this from feature-removal-schedule? What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports (temporary transition config option provided until then) The transition config option will also be removed at the same time. When: before 2.6.19 Why:Unused symbols are both increasing the size of the kernel binary and are often a sign of "wrong API" Who:Arjan van de Ven <[EMAIL PROTECTED]> --- Ping? What: USB driver API moves to EXPORT_SYMBOL_GPL When: February 2008 Files: include/linux/usb.h, drivers/usb/core/driver.c Why:The USB subsystem has changed a lot over time, and it has been possible to create userspace USB drivers using usbfs/libusb/gadgetfs that operate as fast as the USB bus allows. Because of this, the USB subsystem will not be allowing closed source kernel drivers to register with it, after this grace period is over. If anyone needs any help in converting their closed source drivers over to use the userspace filesystems, please contact the [EMAIL PROTECTED] mailing list, and the developers
Re: Feature Removals for 2.6.25
--- What: CONFIG_FORCED_INLINING When: June 2006 Why:Config option is there to see if gcc is good enough. (in january 2006). If it is, the behavior should just be the default. If it's not, the option should just go away entirely. Who:Arjan van de Ven Patch submitted to Arjan, maybe 2.6.25? Ingo picked it up, but no rush for .25, .26 is fine for this as well What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports (temporary transition config option provided until then) The transition config option will also be removed at the same time. When: before 2.6.19 Why:Unused symbols are both increasing the size of the kernel binary and are often a sign of wrong API Who:Arjan van de Ven [EMAIL PROTECTED] this is an ongoing work; symbols get marked unused and then garbage collected when they're due; for example akpm has several of that kind in his pile right now -- 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: Feature Removals for 2.6.25 (USB driver api)
--- Ping? What: USB driver API moves to EXPORT_SYMBOL_GPL When: February 2008 Files:include/linux/usb.h, drivers/usb/core/driver.c Why: The USB subsystem has changed a lot over time, and it has been possible to create userspace USB drivers using usbfs/libusb/gadgetfs that operate as fast as the USB bus allows. Because of this, the USB subsystem will not be allowing closed source kernel drivers to register with it, after this grace period is over. If anyone needs any help in converting their closed source drivers over to use the userspace filesystems, please contact the [EMAIL PROTECTED] mailing list, and the developers there will be glad to help you out. Who: Greg Kroah-Hartman [EMAIL PROTECTED] This is queued up in my tree to go to Linus, see my previous post on lkml and the linux-usb mailing list about this topic. thanks, greg k-h -- 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: Feature Removals for 2.6.25
On Thu, 2008-01-31 at 20:53 -0800, Arjan van de Ven wrote: --- What: CONFIG_FORCED_INLINING When: June 2006 Why:Config option is there to see if gcc is good enough. (in january 2006). If it is, the behavior should just be the default. If it's not, the option should just go away entirely. Who:Arjan van de Ven Patch submitted to Arjan, maybe 2.6.25? Ingo picked it up, but no rush for .25, .26 is fine for this as well OK, it shouldn't be any change from what's there now, but no rush. What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports (temporary transition config option provided until then) The transition config option will also be removed at the same time. When: before 2.6.19 Why:Unused symbols are both increasing the size of the kernel binary and are often a sign of wrong API Who:Arjan van de Ven [EMAIL PROTECTED] this is an ongoing work; symbols get marked unused and then garbage collected when they're due; for example akpm has several of that kind in his pile right now How do they get marked? As this is an ongoing effort, should this be moved to the top of the file, and the actual symbols+date be listed? That would make it easy to figure out what's going away. Something like the following (grep found me two example symbols) Harvey --- From: Harvey Harrison [EMAIL PROTECTED] Subject: [PATCH] feature-removal: document symbols going away Signed-off-by: Harvey Harrison [EMAIL PROTECTED] --- Documentation/feature-removal-schedule.txt | 25 +++-- 1 files changed, 15 insertions(+), 10 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 3a46d1f..0c418e6 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -5,6 +5,21 @@ the work. When the feature is removed from the kernel, it should also be removed from this file. --- +What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports + (temporary transition config option provided until then) + The transition config option will also be removed at the same time. +Why: Unused symbols are both increasing the size of the kernel binary + and are often a sign of wrong API +Who: Arjan van de Ven [EMAIL PROTECTED] + +When: 2.6.25 +fs/open.c:sys_open +fs/read_write.c:sys_read + +When: 2.6.26 + + +--- What: MXSER When: December 2007 @@ -137,16 +152,6 @@ Who:Adrian Bunk [EMAIL PROTECTED] --- -What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports - (temporary transition config option provided until then) - The transition config option will also be removed at the same time. -When: before 2.6.19 -Why: Unused symbols are both increasing the size of the kernel binary - and are often a sign of wrong API -Who: Arjan van de Ven [EMAIL PROTECTED] - - What: USB driver API moves to EXPORT_SYMBOL_GPL When: February 2008 Files: include/linux/usb.h, drivers/usb/core/driver.c -- 1.5.4.rc4.1142.gf5a97 -- 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/
Removing dev.power.power_state (WAS: Feature Removals for 2.6.25)
Quoth Harvey Harrison: Ping? What: dev-power.power_state When: July 2007 Why: Broken design for runtime control over driver power states, confusing driver-internal runtime power management with: mechanisms to support system-wide sleep state transitions; event codes that distinguish different phases of swsusp sleep transitions; and userspace policy inputs. This framework was never widely used, and most attempts to use it were broken. Drivers should instead be exposing domain-specific interfaces either to kernel or to userspace. Who: Pavel Machek [EMAIL PROTECTED] A lot of the infrastructure using that has already been deleted, and there are some incremental improvements pending for 2.6.25: - drivers/input/touchscreen/ads7846.c ... patch fixing this should be in either MM or the input queue - Documentation/power/devices.txt ... patch fixing this is in the suspend tree, due to merge RSN - drivers/spi/spi.c ... patch fixing this is in MM, due to merge with other SPI patches - drivers/pcmcia/ds.c ... at least I *think* that patch got sent But there are still quite a few users left, and a new one was (sigh) recently added. - drivers/rtc/rtc-sa1100.c ... new usage, merged last week - drivers/usb/... has various users, HCDs look easy enough to fix but the other bits will take more thought - drivers/ata/... has some too - drivers/ide/ppc/pmac.c - drivers/spi/... some controller drivers use this (look easy to fix) - drivers/scsi/mesh.c - drivers/input/serio/... has a few users - ... more ... I'll probably send in a few more patches for easy stuff in areas that I touch semi-frequently, but other folk should fix ATA, IDE, SCSI, SERIO, and so forth. It'd be good if Alan would help fix the USB stuff too. I'm not sure what Pavel's doing there... - Dave -- 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: Feature Removals for 2.6.25
Harvey Harrison wrote: Something like the following (grep found me two example symbols) to be honest, nobody reads this file with such detail; the actual UNUSED marking is a lot more louder and people are more likely to notice those for all I care we nuke the entire entry from the removals file. -- 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: Feature Removals for 2.6.25
On Thu, 2008-01-31 at 22:33 -0800, Arjan van de Ven wrote: Harvey Harrison wrote: Something like the following (grep found me two example symbols) to be honest, nobody reads this file with such detail; the actual UNUSED marking is a lot more louder and people are more likely to notice those for all I care we nuke the entire entry from the removals file. Well, if there is interest in having an up-to-date file, I'm willing to do the bookkeeping to make this usable and try to keep it up to date. Anybody think this is worthwhile? Harvey -- 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: Feature Removals for 2.6.25
Ping? What: sk98lin network driver When: Feburary 2008 Why:In kernel tree version of driver is unmaintained. Sk98lin driver replaced by the skge driver. Who:Stephen Hemminger [EMAIL PROTECTED] Sent a removal patch to Jeff, it probably was too big for the mailing list. -- Stephen Hemminger [EMAIL PROTECTED] -- 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/
