On Fri, Dec 16, 2016 at 05:10:18PM +0100, Luis R. Rodriguez wrote: > Ah, well Milo Kim replied and described that the custom fallback is used as to > help load LED effect manually, and suggested a sysfs interface is more ideal [0]. I > agree however its also may be too late, and it depends how wide spread this "userspace" > that relies on this is, we just can't break it. Granted the custom fallback > mechanism was broken since v4.0 (see the fix "firmware: fix usermode helper > fallback loading") so one may argue no one seems to care... > > So this is a judgement call, and the declaration is to point to documentation > to white list uses, as terrible as this one is userspace exists for it. but > more importantly to also help the SmPL grammar report to avoid reporting > already vetted cases. The alarm / cases for the 2 drivers has been issueed, > moving forward the lack of declaration with the custom fallback should trigger > a rant through 0-day so we don't run into the same stupid situation. > > [0] https://marc.info/?l=linux-kernel&m=148168024112445 Milo if sysfs is used can't the old userspace be mapped to use the new sysfs interface through a wrapper of some sort ? What exactly would be needed to ensure old userspace will not break? Why has no one cried after the v4.0 custom fallback mechanism breaking ? How wide spread is this custom userspace ? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-leds" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
