On Thu, Oct 29, 2009 at 4:13 AM, David Miller <davem@xxxxxxxxxxxxx> wrote: > From: Robert Hancock <hancockrwd@xxxxxxxxx> > 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@xxxxxxxxx> > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
