On Friday, March 17, 2017 10:13:13 AM Tejun Heo wrote: > Hello, > > On Fri, Mar 17, 2017 at 03:08:56PM +0100, Bartlomiej Zolnierkiewicz wrote: > > To be honest, the main point here is to make Russell happy. ;-) > > > > This is the second time he brought EBSA110 issue while talking about > > conversion of ARM platforms to use libata PATA so I've finally decided > > to do the patch just to have a reference example of how to deal with > > this and similar devices in a proper way. > > > > Even though the patch can't be tested EBSA110 is still a supported ARM > > platform and the patch should work fine in theory (+ it cannot break > > anything). OTOH it adds an extra code which has some cost from the > > long-term maintenance POV. Anyway, it is up to you to decide what to > > do with it. :-) > > It's fairly low impact and I don't think it's gonna add noticeable > maintenance overhead at all, so that part is fine but it's super weird > to add code which we know not to have any users. It looks like we > can't even test it. Well, this is more general problem. We keep things like ARM EBSA110 platform support in the kernel for some reason.. maybe we shouldn't? > What's the end game here? Is it part of the effort to remove ide? If > so, I have no objection to that but think it isn't a pressing issue > either and the ultimate decision has to come from Dave. I'm just helping in migrating users that are still using ide to libata, enhancing libata's hardware support in the process. I would prefer to have ide removed in the long-term (once there are no known users of it) but Dave has a valid point (see below). This particular patch is more a by-product of the above work than a part of it itself. Dave's current opinion is that we can't prove that all configurations currently supported by ide are supported by libata. Since it can never be really proved (as there are ide drivers for hardware that cannot be tested because of having no active users) he is fine with ide staying in the kernel forever. Which may be not as bad for me personally as I have a lot of contributions there. ;-) Theoretically another option is to finish ide's evolution into "ide compat" layer for SCSI/libata. This would give us full git history from ide to libata support + thin compatibility layer. However with libata PATA availability and hardware being obsolete there is no real need for it and the cost to finish such transition is much higher than cost of ide staying in the kernel forever. Moreover it would need to happen outside of the upstream kernel and there are no guarantees that it would be ever merged (ide is in deep maintenance policy and treated as a "safe fallback" for libata; SCSI & libata changes would need to be agreed on). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- 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
