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 <[email protected]>
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
From: Robert Hancock <[email protected]>
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 <[email protected]>
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.
On Thu, Oct 29, 2009 at 4:13 AM, David Miller <[email protected]> wrote:
> From: Robert Hancock <[email protected]>
> 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 <[email protected]>
>
> 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.
>
From: Robert Hancock <[email protected]>
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.
> > 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
> 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
From: Alan Cox <[email protected]>
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 :-)
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
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,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
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.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
From: Martin Steigerwald <[email protected]>
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.
From: Martin Steigerwald <[email protected]>
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. :-)