| Message ID | 4AE64FCC.4030102@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
From: Robert Hancock <hancockrwd@gmail.com> Date: Mon, 26 Oct 2009 19:41:32 -0600 > The current Kconfig text for CONFIG_IDE doesn't give a hint to users that this > subsystem is currently in maintenance mode and isn't actively developed. > Let's correct this by marking it as deprecated, and also get rid of a bunch of > unnecessary text that doesn't really have anything to do with what the option is > for. > > Signed-off-by: Robert Hancock <hancockrwd@gmail.com> Applied to ide-next-2.6, thanks. But honestly, we have to reword or revert this if certain things don't happen before the next merge window. What it comes to is that two things have to happen before we can completely shut down IDE and schedule it's removal. 1) Add a way for the ATA layer to create compat device nodes so that people can change over to use the ATA layer for their devices without any fstab et al. changes. These compat device nodes do not have to be so featureful that they support hdparm or smartd or anything like that, but they need to work well enough to mount filesystems, and mount swap partitions, and interact with device management systems like udev as if they were real IDE devices. 2) The two or so remaining devices which have IDE support but don't have an ATA layer driver need porting. I plan to work on #1 if I get the time. Someone with the requisite hardware needs to work on #2, and I'm sure whoever wants to work on that will find it easy to get help from some ATA layer experts. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 29, 2009 at 4:13 AM, David Miller <davem@davemloft.net> wrote: > From: Robert Hancock <hancockrwd@gmail.com> > Date: Mon, 26 Oct 2009 19:41:32 -0600 > >> The current Kconfig text for CONFIG_IDE doesn't give a hint to users that this >> subsystem is currently in maintenance mode and isn't actively developed. >> Let's correct this by marking it as deprecated, and also get rid of a bunch of >> unnecessary text that doesn't really have anything to do with what the option is >> for. >> >> Signed-off-by: Robert Hancock <hancockrwd@gmail.com> > > Applied to ide-next-2.6, thanks. > > But honestly, we have to reword or revert this if certain > things don't happen before the next merge window. > > What it comes to is that two things have to happen before > we can completely shut down IDE and schedule it's removal. Well, that's why it's a Kconfig patch and not an entry in the feature removal schedule.. the idea is to tell people that while they can continue using the code for now, it's not under active development and will likely someday go away, so migrate if you can. That doesn't imply that we're close to being able to schedule IDE removal yet. > > 1) Add a way for the ATA layer to create compat device > nodes so that people can change over to use the ATA > layer for their devices without any fstab et al. changes. > > These compat device nodes do not have to be so featureful > that they support hdparm or smartd or anything like that, > but they need to work well enough to mount filesystems, and > mount swap partitions, and interact with device management > systems like udev as if they were real IDE devices. I'm not really sure if this is worthwhile.. is having to update fstab really so onerous as to be worth the trouble? You'd presumably have to enable the creation of the compat device nodes somehow (enabling them by default seems like it would cause a lot of confusion), so it's not like you wouldn't need any config changes that way, either. I think people would be better off just updating their fstab and being done with it.. preferably switching to something like mounting by label or UUID so that things just work even if the devices get reordered when they rearrange their cables or add a new controller, etc. Every Fedora/Red Hat-derived OS has set things up this way by default for years.. > > 2) The two or so remaining devices which have IDE support but > don't have an ATA layer driver need porting. Has anyone gone through and made a list of these? pmac seems like the most obvious one.. > > I plan to work on #1 if I get the time. Someone with the requisite > hardware needs to work on #2, and I'm sure whoever wants to work on > that will find it easy to get help from some ATA layer experts. > -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Robert Hancock <hancockrwd@gmail.com> Date: Thu, 29 Oct 2009 18:19:03 -0600 > I think people would be better off just updating their fstab and being > done with it.. preferably switching to something like mounting by > label or UUID so that things just work even if the devices get > reordered when they rearrange their cables or add a new controller, > etc. Every Fedora/Red Hat-derived OS has set things up this way by > default for years.. You can't just make devices dissapear without providing some kernel option or similar that keeps things working. My very own machines will break unless that happens. And yes I absolutely do consider it too onerous to change my fstab because I have to (or want to be able to) go back to older kernels which will only have the IDE stack enabled. I refuse to have to monkey around with my fstab every time I want to go back and forth. And god forbid I actually want to test some -stable IDE fix on this machine :-) And I know I won't be the only person in this kind of situation. So, proceeding in any other way is really a non-starter. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > 1) Add a way for the ATA layer to create compat device > > nodes so that people can change over to use the ATA > > layer for their devices without any fstab et al. changes. > > > > These compat device nodes do not have to be so featureful > > that they support hdparm or smartd or anything like that, > > but they need to work well enough to mount filesystems, and > > mount swap partitions, and interact with device management > > systems like udev as if they were real IDE devices. > > I'm not really sure if this is worthwhile.. is having to update fstab > really so onerous as to be worth the trouble? You'd presumably have to > enable the creation of the compat device nodes somehow (enabling them > by default seems like it would cause a lot of confusion), so it's not > like you wouldn't need any config changes that way, either. Not worth the pain or the code complexity. Almost no system today hard codes the identifiers. For those that do you can use a udev rule to make symlinks. > > 2) The two or so remaining devices which have IDE support but > > don't have an ATA layer driver need porting. > > Has anyone gone through and made a list of these? pmac seems like the > most obvious one.. Pmac is probably the only one that matters. It basically needs an alternate set of DMA sg drivers for the MAC DMA, the rest is very "normal". The other is SGIIOC4 which I doubt anyone cares about. There are a few other things that I think could do with addressing particularly better IRQ unmasking for both polled PIO (embedded devices) and interrupt driven PIO on relatively sane hardware would be helpful particularly in the embedded world. IDE will self correct in time anyway - new hardware doesn't work with it, newer embedded devices are also moving away from compact flash, so it'll die of its own accord. As such while things like pmac support in libata will be nice I don't think there is any need to go around obsoleting it or pressuring people to move stacks. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> And I know I won't be the only person in this kind of situation. > > So, proceeding in any other way is really a non-starter. Then keep old IDE until the hardware rots. Its not worth contaminating libata and the scsi core with magic glue that only Dave Miller uses ;) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Alan Cox <alan@lxorguk.ukuu.org.uk> Date: Fri, 30 Oct 2009 00:33:37 +0000 > Then keep old IDE until the hardware rots. Its not worth contaminating > libata and the scsi core with magic glue that only Dave Miller uses ;) Fair enough :-) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/29/2009 08:32 PM, Alan Cox wrote: > IDE will self correct in time anyway - new hardware doesn't work with it, > newer embedded devices are also moving away from compact flash, so it'll > die of its own accord. > > As such while things like pmac support in libata will be nice I don't > think there is any need to go around obsoleting it or pressuring people > to move stacks. This has been my general policy... people will continue moving away from IDE over time. Not much need to do anything but let sleeping dogs lie. libata definitely needs pmac support, that is the really only big missing driver piece, IMO. On compatibility: while a compat ATA block device would be nice -- having a native Linux block driver for ATA disks has been a longstanding "want" since Day One -- a compat block device purely for these situations would be quite a bit of work for a tiny-and-shrinking userbase. And that totally ignores an idea of attempting compatibility with IDE's ATAPI setup, another huge can-o-worms. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Freitag 30 Oktober 2009 schrieb David Miller: > And yes I absolutely do consider it too onerous to change my fstab > because I have to (or want to be able to) go back to older kernels > which will only have the IDE stack enabled. I refuse to have to > monkey around with my fstab every time I want to go back and forth. You don't need to when you used UUID or LABEL - I prefer the later cause its more readable. Actually I never quite understood while one would want to use dynamic things like /dev/hdd or /dev/sdb in the first place. Thats for me not that much better than C: or D:. Connect your harddisks differently and you are screwed. On AmigaOS partitions were refered by names since the beginning. When I copied my OS to a different harddisk I gave the new partition the same name, copied all files over, removed the old harddisk or renamed the old partition and reduced its boot priority and be done with it. (Not that AmigaOS had a fstab that I could have edited anyway.) This way I could connect an IDE disk with the IDE controller on board, an IDE controller card like FastATA or via bridge to the UWSCSI controller on the CyberStorm PPC turbo board without having to change any configuration in order to be able to boot. (Another thing to copy would be how removable storage devices are handled. If you remove a disk or usb stick prematurely while the OS is still writing to it you get a "You MUST insert volume xyz again!" requester and if you do, the writes will be completed. I never have seen any other OS that does it this sane way as a standard. Other OS either disallow device removal where possible or loose data.) Ciao,
Am Freitag 30 Oktober 2009 schrieb Martin Steigerwald: > Am Freitag 30 Oktober 2009 schrieb David Miller: > > And yes I absolutely do consider it too onerous to change my fstab > > because I have to (or want to be able to) go back to older kernels > > which will only have the IDE stack enabled. I refuse to have to > > monkey around with my fstab every time I want to go back and forth. > > You don't need to when you used UUID or LABEL - I prefer the later > cause its more readable. Actually I never quite understood while one > would want to use dynamic things like /dev/hdd or /dev/sdb in the > first place. Thats for me not that much better than C: or D:. Connect > your harddisks differently and you are screwed. One thing to add: If you use a InitRD, you can use UUID or LABEL in GRUB 1 as well. I believe GRUB 2 at leasts supports UUID out of the box, but better check this, before relying on my word.
From: Martin Steigerwald <Martin@lichtvoll.de> Date: Fri, 30 Oct 2009 09:15:51 +0100 > You don't need to when you used UUID or LABEL - I prefer the later cause > its more readable. Actually I never quite understood while one would want > to use dynamic things like /dev/hdd or /dev/sdb in the first place. Thats > for me not that much better than C: or D:. Connect your harddisks > differently and you are screwed. Turns out I actually have UUID mounts, great! Only hardcoded thing in my fstab is /dev/hdc for the cdrom. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Martin Steigerwald <Martin@lichtvoll.de> Date: Fri, 30 Oct 2009 09:18:39 +0100 > One thing to add: If you use a InitRD, you can use UUID or LABEL in GRUB 1 > as well. I believe GRUB 2 at leasts supports UUID out of the box, but > better check this, before relying on my word. Since I recently implement sparc64 support for GRUB2 I know that indeed it does support UUID out of the box. But grub2 sparc64 support is very new and the existing sparc64 boot loader 'SILO' doesn't support UUIDs. Personally, I also don't use initrds, I avoid them like the plague. :-) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig index 9a5d0aa..98ccfeb 100644 --- a/drivers/ide/Kconfig +++ b/drivers/ide/Kconfig @@ -7,50 +7,25 @@ config HAVE_IDE bool menuconfig IDE - tristate "ATA/ATAPI/MFM/RLL support" + tristate "ATA/ATAPI/MFM/RLL support (DEPRECATED)" depends on HAVE_IDE depends on BLOCK ---help--- - If you say Y here, your kernel will be able to manage low cost mass - storage units such as ATA/(E)IDE and ATAPI units. The most common - cases are IDE hard drives and ATAPI CD-ROM drives. - - If your system is pure SCSI and doesn't use these interfaces, you - can say N here. - - Integrated Disk Electronics (IDE aka ATA-1) is a connecting standard - for mass storage units such as hard disks. It was designed by - Western Digital and Compaq Computer in 1984. It was then named - ST506. Quite a number of disks use the IDE interface. - - AT Attachment (ATA) is the superset of the IDE specifications. - ST506 was also called ATA-1. - - Fast-IDE is ATA-2 (also named Fast ATA), Enhanced IDE (EIDE) is - ATA-3. It provides support for larger disks (up to 8.4GB by means of - the LBA standard), more disks (4 instead of 2) and for other mass - storage units such as tapes and cdrom. UDMA/33 (aka UltraDMA/33) is - ATA-4 and provides faster (and more CPU friendly) transfer modes - than previous PIO (Programmed processor Input/Output) from previous - ATA/IDE standards by means of fast DMA controllers. - - ATA Packet Interface (ATAPI) is a protocol used by EIDE tape and - CD-ROM drives, similar in many respects to the SCSI protocol. - - SMART IDE (Self Monitoring, Analysis and Reporting Technology) was - designed in order to prevent data corruption and disk crash by - detecting pre hardware failure conditions (heat, access time, and - the like...). Disks built since June 1995 may follow this standard. - The kernel itself doesn't manage this; however there are quite a - number of user programs such as smart that can query the status of - SMART parameters from disk drives. + If you say Y here, your kernel will be able to manage ATA/(E)IDE and + ATAPI units. The most common cases are IDE hard drives and ATAPI + CD-ROM drives. + + This subsystem is currently in maintenance mode with only bug fix + changes applied. Users of ATA hardware are encouraged to migrate to + the newer ATA subsystem ("Serial ATA (prod) and Parallel ATA + (experimental) drivers") which is more actively maintained. To compile this driver as a module, choose M here: the module will be called ide-core. For further information, please read <file:Documentation/ide/ide.txt>. - If unsure, say Y. + If unsure, say N. if IDE
The current Kconfig text for CONFIG_IDE doesn't give a hint to users that this subsystem is currently in maintenance mode and isn't actively developed. Let's correct this by marking it as deprecated, and also get rid of a bunch of unnecessary text that doesn't really have anything to do with what the option is for. Signed-off-by: Robert Hancock <hancockrwd@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html